当我在MVVM应用程序中处理业务逻辑时。我应该在Model或ViewModel上执行此操作吗？
例如，如果我想在资产重新评估后重新计算成本，我应该对模型进行操作吗？
在ViewModel上执行此操作是否有优势？
如果我有ViewModel列表会发生什么，但我想将其转换为模型列表，以便我可以进行一些处理？我可以将Model公开为ViewModel的属性（并使用它来构建Models列表）。但这意味着View将能够访问原始模型的属性
答案 0 :(得分：10)
模型的目的是表示（或建模）您的业务领域。因此，根据定义，业务逻辑在模型中，而不是ViewModel。
ViewModel的工作是公开Model的属性和字段，并准备它们供View使用。
例如，描绘一个银行应用程序。模型可以代表一个帐户。也许该模型具有帐户余额。模型的工作可能是跟踪平衡并确保维持某些不变量（例如不允许大于余额的提款）。 ViewModel的工作可能是将余额转换为在视图中用作绑定的字符串。
您希望尽可能多地保留ViewModel的逻辑，以保持代码的可重用性和松散耦合。
答案 1 :(得分：9)
我的建议是将逻辑放在服务层中。 这是视图模型和模型之间的中间层（在面向实体的范例中，它应该只包含属性）。 所以正确的生命周期可能是： 查看模型 - ＆gt;服务 - ＆gt;模型处理。 如果需要，这还允许通过其他视图模型重用业务逻辑代码
答案 2 :(得分：1)
如果您正在构建Web应用程序，请使用该模型;如果您正在构建LAN /桌面应用程序，那么模型即一个级别，即域级别。
您的问题 - 在重新评估资产后重新计算成本 - 可能不仅仅是用户界面问题。后端应用程序可能希望执行相同操作（例如，用于自动导入数据）。然后您可以选择复制业务逻辑或重新连接到现有逻辑。
对后端使用相同的模型也没有错。但是模型 - 特别是断开连接的模型 - 往往是大型数据结构，因为它们需要带来参考表中的所有数据（除非你想要往返服务器并牺牲你的GUI体验）。如果使用模型，这可能会影响性能。
答案 3 :(得分：0)
如果你的模型包含计算所需的数据，你可以使用model.if模型不包含数据意味着创建视图模型并获取数据来进行计算。（关于业务逻辑）
如果要传递此数据以查看创建视图模型它可以改善代码重用机会