WPF MVVM vs Razor Page MVVM

Question

Шаблон MVVM в WPF делает сильный упор на полное отделение ViewModel от пользовательского интерфейса, и в идеале в файле с выделенным кодом ничего или очень мало. Это позволяет повторно использовать ViewModel для различных типов интерфейса.

Шаблон MVVM в Razor Pages имеет программный код в виде ViewModel и тесно связан с веб-логикой с помощью методов OnGet и OnPost.

Таким образом, тщательно разработанная развязанная WPF ViewModel не может служить Web ViewModel (или, возможно, может использоваться из Модель веб-страницы?)

Есть ли что-то, чего мне не хватает, и почему такая разница между MVVM в WPF (развязана) и MVVM в Razor Pages (соединена)?

Если бы мы применили подход Razor Pages к WPF, то программным кодом стал бы ViewModel - который я никогда не видел никому рекомендовать.

Answer 1

Чтобы прояснить ситуацию: WPF вводит связь между представлением и моделью представления так же, как Razor Pages. Модель представления является слоем представления данных, чтобы разорвать зависимость между представлением и моделью. Таким образом, вид может быть изменен без изменения каких-либо моделей. Затем сама модель представления связывается с моделью, поскольку она выбирает требуемые данные (например, из службы или базы данных). Это поведение реализуется в Razor Pages в едином шаблоне, когда модели представления реализуют абстрактный PageModel и следуют соглашению, предоставляя соответствующие необязательные обработчики действий (например, OnGet ()). Эти обработчики будут вызываться платформой каждый раз, когда для страницы будет отправлен HTTP-запрос. Вы должны получить или манипулировать данными модели на основе метода запроса (например, GET, DELETE, POST, PUT, ...) и затем представить их представлению. Соглашение описывает шаблон именования этих обработчиков, чтобы инфраструктура могла их идентифицировать.

Таким образом, вы найдете одинаковую степень связи между слоями в WPF MVVM и Razor Pages MVVM. Поскольку модель представления в RazorPages инкапсулирует контекст конкретной страницы, именование исходного файла следует соглашению об именовании («page name.cshtml.cs»), чтобы сделать связь видимой в вашей файловой системе. Это не файл с выделенным кодом, как файл класса partial представления в WPF.

Answer 2

Я не уверен, почему вы настаиваете на использовании Razor Pages, когда есть MVC (Model-View-Controller).

Вместо этого вы должны использовать шаблон MVC. Вы получаете тот же синтаксис бритвы, но не связаны.

Razor Pages были введены как форма преемника WebForms (которая сама пыталась имитировать Windows Forms, что также не связано с разделением).

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

По этой причине у ViewModels MVVM также есть (в дополнение к свойствам для привязки модели) такие вещи, как команды, и они могут быть ориентированы на навигацию (т.е. через интерфейсы INavigationAware Prism).

В этом контексте ViewModels не имеют большого значения в серверных веб-приложениях, поскольку HTTP сам по себе не имеет состояния, когда ViewModels поддерживает состояние.

Таким образом, ViewModels в MVC просто сводятся к DTO (объектам передачи данных), которые имеют базовую проверку (через атрибуты проверки). ViewModels в MVC-приложениях не имеют никакой логики представления, поскольку она визуализируется в HTML, а большая часть логики представления происходит снаружи через JavaScript (что происходит при нажатии кнопки, как отформатировать дату или валюту для пользователя).

При этом вам не нужны полноценные ViewModels в приложении ASP.NET Core, по крайней мере, для серверной части. Однако, если вы используете технологию на стороне клиента (Angular, Vue.js, React), вы можете использовать ViewModels для улучшения функциональности и отделения ее от View.

Фактически, угловые компоненты в значительной степени являются ViewModel и выполняют ту же задачу, что и ViewModels в шаблоне MVVM (в него можно внедрять сервисы, есть односторонние или двусторонние привязки, проверка ввода и в них заложена логика представления).

TL; DR : вам не нужны ViewModel, поскольку они определены в MVVM, просто DTO-подобные классы, чтобы упростить их использование в (Razor) шаблоне представления. И не используйте Razor Pages для развязки.