当我在 MVVM 应用程序中处理业务逻辑时。我应该在 Model 还是 ViewModel 上执行此操作？
例如，如果我想在资产被重新估价后重新计算成本，我应该对模型进行操作吗？
在 ViewModel 上这样做有优势吗？
如果我有一个 ViewModel 列表，但我想将其转换为一个模型列表以便进行一些处理，会发生什么？我可以将模型公开为 ViewModel 的属性（并使用它来构建模型列表）。但这意味着 View 将能够访问原始模型的属性
【问题讨论】：
我的建议是将逻辑放在服务层中。 这是视图模型和模型之间的中间层（在真正的面向对象范例中，它应该只包含属性）。 所以正确的生命周期可能是： 查看模型 -> 服务 -> 模型处理。 如果需要，这还允许通过其他视图模型重用业务逻辑代码
【讨论】：
UpdateTiming() 的方法，它计算三个属性。最初，在重构时，我将 ViewModel 作为参数传入，以便它可以设置这些值并且 UI 会更新。但现在服务与 ViewModel 紧密耦合。相反，我应该将模型作为参数传递并返回一个元组，然后从 ViewModel 中更新属性吗？似乎有很多额外的代码。
new 向上一个 ViewModel 对象。说得通？因此，在大多数情况下，您需要将 Model 转换为 ViewModel，有时反之亦然，您可以使用像 this one 这样的映射器。
模型的目的是代表（或建模）您的业务领域。因此，根据定义，业务逻辑位于模型中，而不是视图模型中。
ViewModel 的工作是公开 Model 的属性和字段，并准备好供 View 使用。
例如，想象一个银行应用程序。模型可能代表一个帐户。也许模型有一个帐户余额。模型的工作可能是跟踪余额并确保维护某些不变量（例如不允许大于余额的提款）。 ViewModel 的工作可能是将余额转换为字符串，用作 View 中的绑定。
您希望尽可能多地保留 ViewModel 之外的逻辑，以保持您的代码可重用和松散耦合。
【讨论】：
如果您正在构建网络应用程序，请使用该模型；如果您正在构建 LAN/desk 应用程序，则在模型下面一层，即域级别。
您的问题 - 在资产重新估价后重新计算成本 - 可能不仅仅是用户界面问题。后端应用程序可能想要做同样的事情（例如，自动导入数据）。然后，您可以选择复制业务逻辑或重新布线到现有逻辑。
后端使用相同的模型也没有错。但是模型——尤其是断开连接的模型——往往是大型数据结构，因为它们需要从引用表中携带所有数据（除非你想往返于服务器并牺牲你的 GUI 体验）。如果使用模型，这可能会影响性能。
【讨论】：
如果您的模型包含计算所需的数据，您可以使用模型。如果模型不包含数据意味着创建视图模型并获取数据来进行计算。（关于业务逻辑）
如果您想将这些数据传递给视图创建视图模型，它会提高代码重用机会
【讨论】：