<分区>
在我们的 KnockoutJS 项目(一个 MVVM 数据绑定(bind)库)中，我们有两种类型的 viewModel 会发生冲突。 一方面，我们有像 View 一样架构的 View 模型。假设我有一个允许我创建用户的表单，它是一个 formVM。 viewModel 的每个属性都是表单的一个属性。每个属性都是一个计算值，将写入业务模型。
另一方面，我们的 viewModel 的架构类似于业务模型。在我们之前的示例中，它将是一个 userVM，具有模型的基本属性以及其他属性，例如根据用户名等计算的标签。在 View html 中，我们在这里使用 userVM.label 例如。
一个比另一个更正确吗？你用哪个？
最佳答案
我会说两者都不正确。您的 View 模型中绝对不应该有任何业务逻辑。此逻辑属于您的业务层。 View 模型应该只包含一个模型(将可观察对象绑定(bind)到您的表单字段)并在适当的时候将其传递给业务层。
严格来说，我会说 View 模型应该只包含 View 模型(可观察对象)、事件处理程序和很少的其他内容。当用户与 UI 交互时，您的事件处理程序将收集必要的信息并将其传递给业务层。该业务层可能会返回 View 的数据，例如您提到的计算标签。然后可以将该值插入到“哑”可观察对象中，因此无需任何业务逻辑进入您的 View 模型即可显示在 View 中。
当用户点击保存时，您从可观察对象中获取数据并将其传递给业务层，业务层将做出响应(更改已成功保存，或者出现问题)。 View 模型可以使用此响应来更新 UI。
简而言之， View 模型处理 UI 显示的内容，并处理用户完成的任何交互。但它通常只包含将信息传递给包含智能的模块的愚蠢功能。
这是我的观点，老实说:在实践中，我自己也经常违反这一原则。
关于javascript - MVVM:viewModel 的架构应该像 View 还是模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26137523/