在我们的 KnockoutJS 项目（一个 MVVM 数据绑定库）中，我们有两种类型的 viewModel 发生冲突。 一方面，我们有像视图一样架构的视图模型。所以假设我有一个允许我创建用户的表单，它是一个 formVM。 viewModel 的每个属性都是表单的一个属性。每个属性都是计算的，将写入业务模型。
另一方面，我们的视图模型的架构类似于业务模型。在我们之前的示例中，它将是一个 userVM，具有模型的基本属性以及其他诸如根据用户名计算的标签等。在视图 html 中，我们在这里使用 userVM.label 示例。
一个比另一个更正确吗？你用的是哪一种？
【问题讨论】：
标签： javascript mvvm knockout.js architecture
我会说两者都不正确。您的视图模型中绝对不应该有任何业务逻辑。此逻辑属于您的业务层。 viewmodel 应该只保存一个模型（与您的表单字段绑定的可观察对象）并在适当的时候将其传递给业务层。
严格来说，我会说视图模型应该只包含您的视图模型（可观察对象）、事件处理程序以及其他很少的内容。当用户与 UI 交互时，您的事件处理程序将收集必要的信息并将其传递给业务层。此业务层可能会返回视图的数据，例如您提到的计算标签。然后可以将此值插入到“哑”可观察对象中，因此可以在视图中显示，而无需任何业务逻辑进入您的视图模型。
当用户点击保存时，您从可观察对象中获取数据并将其传递给业务层，业务层将做出响应（成功保存更改，或者出现问题）。视图模型可以使用此响应来更新 UI。
简而言之，视图模型处理 UI 显示的内容，并处理用户进行的任何交互。但它通常只包含将信息传递给包含智能的模块的愚蠢功能。
这是我的观点，老实说：在实践中，我自己也经常违反这条原则。
【讨论】：
pubsub.subscribe('label-changed', function (newLabelValue) { myLabelObservable(newLabelValue); });（或简而言之：pubsub.subscribe('label-changed', myLabelObservable);）