WPF中的MVVM模式非常强调将ViewModel与UI完全分离，理想情况下，代码隐藏文件中没有任何东西或很少。这允许将ViewModel重用于不同类型的接口。
Razor Pages中的MVVM模式具有代码隐藏作为ViewModel，并且与OnGet和OnPost方法的Web逻辑紧密耦合。
因此，精心设计的解耦WPF ViewModel不能作为Web ViewModel（或者可以从网页模型中使用？）
有什么我缺少的，为什么WPF（解耦）中的MVVM和Razor Pages（耦合）中的MVVM之间存在这样的差异？
如果我们将Razor Pages方法应用于WPF，那么代码隐藏将成为ViewModel - 我从未见过任何人推荐过。
为了清楚起见：WPF在视图和视图模型之间引入了与Razor Pages相同的耦合。视图模型是数据表示层，以便打破视图和模型之间的依赖关系。因此可以在不修改任何模型的情况下更改视图。然后视图模型本身耦合到模型，因为它获取所需数据（例如，从服务或数据库获取）。通过使视图模型实现抽象PageModel并通过提供适当的可选动作处理程序（例如OnGet（））遵循约定，在Razor页面中以统一模式实现此行为。每当为页面发出HTTP请求时，框架都将调用这些处理程序。您可以根据请求方法（例如GET，DELETE，POST，PUT，...）获取或操作模型数据，然后将其呈现给视图。该约定描述了这些处理程序的命名模式，以便框架可以识别它们。
因此，您将在WPF MVVM和Razor Pages MVVM中的层之间找到相同程度的耦合。由于RazorPages中的视图模型封装了特定页面的上下文，因此源文件命名遵循命名约定（“page name.cshtml.cs”），以使关系在文件系统中可见。它不是像WPF中视图的partial类文件那样的代码隐藏文件。
当有MVC（模型 - 视图 - 控制器）时，我不确定为什么你坚持使用Razor Pages。
您应该使用MVC模式。你得到相同的剃刀语法，但解耦。
Razor Pages是作为WebForms的继承者的一种形式而引入的（它本身试图模仿Windows Forms，而不是解耦两者）。
如果我们回顾历史，MVVM就是要充分利用WPF的双向模型绑定，它可以作为UI和应用层之间的一个独立层，可以将表示逻辑放入（逻辑紧密耦合到Presentation，这是一个UI关注点而不是与UI分离的应用程序层。
由于这个原因，MVVM的ViewModel也有（除了模型绑定的属性），像命令之类的东西，可能是导航识别（即通过Prism的INavigationAware接口）。
在这种情况下，ViewModel在服务器端Web应用程序中没有多大价值，因为HTTP本身在ViewModels维护状态的情况下是无状态的。
因此，MVC中的ViewModel简化为DTO（数据传输对象），它具有基本验证（通过验证属性）。 MVC应用程序中的ViewModel没有任何表示逻辑，因为它被渲染成HTML并且大多数表示逻辑通过JavaScript发生在外部（当点击按钮时会发生什么，如何为用户格式化日期或货币）。
话虽这么说，你并不需要在ASP.NET核心应用程序中使用完整的ViewModel，至少不需要服务器端部分。但是，如果您使用的是客户端技术（Angular，Vue.js，React），则可以使用ViewModels来增强功能并将其与View分离。
事实上，angular components几乎是ViewModel，并且完成了与MVVM模式中的ViewModel相同的任务（可以将服务注入其中，具有单向或双向绑定，输入验证和一个放置表示逻辑）。
TL; DR：你真的不需要ViewModels，因为它们是在MVVM中定义的，只是类似DTO的类，可以更容易地在（Razor）视图模板中使用它们。并且不要使用Razor Pages进行解耦。