В настоящее время я пытаюсь разобраться с MVVM для WPF - я имею в виду не концептуально, а вокруг того, чтобы сделать что-то, что находится дальше от проторенной дорожки, чем тупой CRUD.

Что я заметил, так это то, что многие фреймворки, и большинство / все посты в блоге, были написаны «давным-давно».

Это потому, что теперь это старая шляпа, и блогеры перешли на Next Big Thing, или просто потому, что они сказали все, что можно сказать?

Другими словами, есть ли что-то, что я здесь упускаю?

MVVM не устарел, но с самого начала был переоценен. Мне это никогда не нравилось, и это слишком долго удерживало меня в WinForms; не видя леса за деревьями, я выбросил ребенка с водой. Теперь я получаю WPF, и у меня возникает идея, что я не хочу смешивать код с разметкой, но я предпочитаю стиль Android, в котором разметка размещается в одном месте и разыменовывается с помощью приведения в моем коде (что также можно сделать в WPF, даже хотя это никогда не было модным, чтобы сделать это по любой причине).

Таким образом, вы получаете более детальный контроль и вам не нужно беспокоиться обо всей «измененной» обработке везде. Я чувствую, что это на самом деле более тестируемо, потому что тесты не всегда поймают его, если вы пропустите «onbound» событие.

Вы теряете немного «декларативной» -ностиности, которая в наши дни кажется тенденцией (например, если два виджета отображаются на одно и то же значение, в MVVM вы можете просто сделать это, тогда как с императивным кодом вы должны установить оба по отдельности) , Но даже с MVVM это работает только во вспомогательном случае. Если какой-то виджет должен отображать журнал другого виджета, то вам нужно написать другой обработчик и другое событие «onchanged», и в итоге вам придется расширить определение «декларативного», чтобы сказать, что это так.

Обновление 2015 года

WPF MVVM был (и) эволюционен для своего времени. Как был WPF. Но у них обоих были бородавки. Обычный WPF слишком много в него встроил (плюс он был построен на XML), и с ним было немного трудно справиться. (Действительно, если бы WPF просто использовал более «библиотечный» подход, а не «каркасный» подход, он мог бы превратиться в действительно крутой материал, и вся техническая вселенная могла бы теперь быть совершенно другой). Идея о MVVM была велика, но пытается подогнать MVVM в WPF был несколько Hacky , поскольку 1) C # не мог выразить это без большого количества шаблонного, и 2) WinForms реликвии , такие как модальные всплывающие окна были все еще идеологически распространены , но не мог быть легко представленным в MVVM. Таким образом все это отстой.

Тем не менее, это все еще единственный реалистичный вариант в Windows, когда вам нужна прозрачность или графический процессор для больших приложений.

Реакт, конечно, сделал MVVM устаревшим. Я был разочарован тем, что у VS2015 не было встроенного счетчика. На данный момент мы все еще застряли с использованием необработанного WPF (который в порядке, но чувствует себя старым (на самом деле кажется таким же старым, как winforms) и не имеет тонны встроенной функциональности (ощущается как какой-то крутой, но заброшенный проект) или с -VVVM, который на данный момент выглядит как пустая трата времени, так как даже хороший MVVM (угловой 1) был выявлен из-за его недостатков.

Я бы избегал WPF MVVM. Это дополнительный слой, и никто больше не заботится об этом.

Все сказано и сделано, есть предел тому, что вы можете сделать с помощью инфраструктуры MVVM.

Они «сделаны», так как WPF не продвигается с тех пор, как Microsoft выпустила его. Если бы были обновления в технологии, библиотеки тоже должны были бы обновиться. Этого не произошло.