在使用MVVM模式完成了几个项目之后，我仍然在为ViewModel的角色而挣扎：
我过去所做的：仅将模型用作数据容器。在ViewModel中放置逻辑以操作数据。（这是商业逻辑吗？）缺点：逻辑是不可重用的。
我现在正在尝试的是：使ViewModel尽可能薄。将所有逻辑移动到模型层中。仅在ViewModel中保留演示逻辑。缺点：如果数据在模型层内更改，则会使UI通知非常痛苦。
因此，我将给你一个例子，让它更清晰：
场景：重命名文件的工具。类：文件：表示每个文件；规则：包含如何重命名文件的逻辑；
如果我遵循方法1：为文件、规则和视图创建ViewModel-
如果我遵循方法2：创建一个新的模型类-
将业务逻辑放入视图模型中是一种非常糟糕的做事方式，所以我将很快地说永远不要这样做，并继续讨论第二种选择。
将逻辑放入模型中更加合理，这是一个很好的开始方法。有哪些弊端？你的问题说
因此，如果Renamer模型被触发以通过方法调用操作一些数据，ViewModel没有任何线索来操作哪些数据。因为模型不包含任何属性更改通知，我会避免这种情况。
好吧，让你的模型实现INotifyProperty tyChanged肯定会让你继续做更好的事情。然而，有时确实不可能做到这一点——例如，模型可能是一个部分类，其中属性由工具自动生成，不会引发更改通知。这很不幸，但不是世界末日。
如果你想买东西，那么就得有人付钱；如果不是模型给出了这样的通知，那么您只有两个选择：
第一个选项同样是一个坏主意，因为实际上它会回到将“业务逻辑”放在视图模型中。虽然没有将所有业务逻辑都放在视图模型中那么糟糕，但仍然如此。
第二种选择更有希望（不幸的是还有更多工作要实施）：
有关这种实现的更多信息，请参见我在这里和这里的回答。
这两种方法都有效，但还有第三种方法：在模型和VM层之间实现服务。如果你想让你的模型保持沉默，服务可以提供一个与UI无关的中间人，以可重用的方式强制执行你的业务规则。
因为模型不包含任何PropertyChange通知，我将避免这种情况
你为什么回避这个？不要误解我的意思，我倾向于让我的模型尽可能的简单，但是在你的模型中实现变更通知有时是有用的，而且你只依赖于< code >系统。ComponentModel。它完全与用户界面无关。
我执行以下操作
>
仅具有XAML视图逻辑的视图
处理单击处理程序和创建新视图模型的ViewModel。处理路由事件等。
模型，它是我的数据容器和验证模型数据的业务逻辑。
用数据填充模型的服务。例如调用Web服务器、从磁盘加载、保存到磁盘等。根据示例，我的模型和服务通常都会实现IProperty tyChanged。或者他们可能有事件处理程序。
任何复杂的应用程序都需要另一层。我称之为模型服务，视图，视图模型。该服务抽象出您的业务逻辑，并将模型实例作为依赖项，或者创建一个模型。
