谁能澄清这些术语。
我发现它们非常模糊或依赖于上下文。
例如，我们有一个包含项目列表的 VM。选择不仅影响按钮的可访问性（即命令可以执行），还影响 VM 的行为：一个或几个项目需要同时编辑很重要。
第二个示例是创建新项的过程。
用户提供数据后，我们将项目添加到项目集合中，从而将其插入列表中，并希望使其处于选中状态并聚焦。现在，我们通过引入项 VM 的IsSelected和IsFocused属性来实现此目的。真正的工作是由视图通过绑定、附加属性和行为完成的。
我们团队的一些成员坚持认为，向虚拟机添加这种属性（IsVisible、IsSelected、IsFocused等）会给虚拟机带来UI逻辑，这不是一个好的做法，因为UI和表示逻辑是混合的。
对我来说，遵循模式是重要的，但更重要的是不要重复自己。我更喜欢代码隐藏中的绑定和几行，而无需将 DataContext 强制转换为具体的 VM 类型、调用 VM 的方法等。
然而，我不喜欢圣战，并承认由于对这两个术语的误解以及彼此分离的标准，我可能是错误的。
表示逻辑放在 VM 中并在其上具有 IsEnabled 等属性很重要，因为这使其可测试。这也降低了视图的复杂性，从而减少了无法进行单元测试的代码量。
此外，我对你的同事可能拥有的关于为什么 VM 中的表示逻辑不是最佳实践的任何参考资料感兴趣。恕我直言，UI 是表示层的一部分，VM 的目的是对视图进行建模。因此，将表示逻辑放在这里似乎是很自然的。
附加编辑：
从实现 MVVM 模式
视图的职责是定义用户在屏幕上看到的内容的结构和外观。理想情况下，视图的代码隐藏仅包含调用 InitializeComponent 方法的构造函数。在某些情况下，代码隐藏可能包含 UI 逻辑代码，这些代码实现在可扩展应用程序标记语言 （XAML） 中难以表达或效率低下的视觉行为，例如复杂动画，或者当代码需要直接操作作为视图一部分的可视元素时。不应在需要单元测试的视图中放置任何逻辑代码。通常，视图代码隐藏中的逻辑代码将通过 UI 自动化测试方法进行测试。