WPF MVVM vs Razor Page MVVM

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

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

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

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

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

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

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

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

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

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

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

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