Eti*_*and 6 .net c# wpf mvvm asp.net-core
WPF 中的 MVVM 模式非常强调将 ViewModel 与 UI 完全分离，理想情况下，代码隐藏文件中什么也没有或很少。这允许将 ViewModel 重用于不同类型的界面。
Razor Pages 中的 MVVM 模式具有作为 ViewModel 的代码隐藏，并通过 OnGet 和 OnPost 方法与 Web 逻辑紧密耦合。
因此，精心设计的解耦 WPF ViewModel 不能作为 Web ViewModel（或者可以从网页 Model 中使用？）
有没有我遗漏的东西，为什么 WPF 中的 MVVM（解耦）和 Razor Pages 中的 MVVM（耦合）之间存在如此大的差异？
如果我们将 Razor Pages 方法应用于 WPF，那么代码隐藏将成为 ViewModel —— 我从未见过有人推荐过它。
Tse*_*eng -1
我不知道当有 MVC（模型-视图-控制器）时，您为什么坚持使用 Razor Pages。
您应该改用 MVC 模式。您将获得相同的 razor 语法但解耦。
Razor Pages 是作为 WebForms 的后继者形式引入的（WebForms 本身试图模仿 Windows 窗体，但这两者都不是为了解耦）。
如果我们回顾几年历史，MVVM 将充分利用 WPF 双向模型绑定的全部功能，该绑定充当 UI 和应用程序层之间的独立层，可以在其中放置表示逻辑（与应用程序紧密耦合的逻辑）。表示，这是一个 UI 问题，而不是与 UI 分离的应用程序层）。
由于这个原因，MVVM 的 ViewModel 还具有（除了模型绑定的属性）、命令之类的东西，并且可能具有导航意识（即通过 Prism 的INavigationAware界面）。
在这种情况下，ViewModel 在服务器端 Web 应用程序中没有多大价值，因为 HTTP 本身是无状态的，而 ViewModel 则维护状态。
因此，MVC 中的 ViewModel 被简单地简化为 DTO（数据传输对象），它具有基本的验证（通过验证属性）。MVC 应用程序中的 ViewModel 没有任何表示逻辑，因为它呈现为 HTML，并且大多数表示逻辑通过 JavaScript 在外部发生（单击按钮时会发生什么，如何为用户设置日期或货币的格式）。
话虽如此，您实际上并不需要在 ASP.NET Core 应用程序中使用成熟的 ViewModel，至少对于服务器端部分而言是如此。但是，如果您使用客户端技术（Angular、Vue.js、React），您可以利用 ViewModel 来增强功能并将其与视图分离。
事实上，Angular 组件几乎就是 ViewModel，并且完成与 MVVM 模式中的 ViewModel 相同的任务（可以将服务注入其中，具有 1 路或 2 路绑定、输入验证以及将表示逻辑放入其中）。
TL;DR：您实际上并不需要 ViewModel，因为它们是在 MVVM 中定义的，只需要类似 DTO 的类，以便更轻松地在 (Razor)View 模板中使用它们。并且不要使用 Razor Pages 来解耦。