演示逻辑vs UI逻辑

任何人都可以澄清这些条款。
我发现它们非常模糊或与上下文相关。演示逻辑vs UI逻辑

例如，我们有一个VM与项目列表。该选择不仅影响按钮的可访问性（即，命令可以执行），还影响VM的行为：重要的是一个或多个项目需要同时编辑。

第二个示例是创建新项目的过程。
在用户提供数据后，我们将项目添加到项目集合中，从而将其插入到列表中，并希望将其选中并聚焦。现在我们通过为项目的VM引入IsSelected和IsFocused属性来完成此操作。真正的工作是通过视图通过绑定，附加属性和行为完成的。

我们的团队insits的一些成员，加入这类性质的（IsVisible，IsSelected，IsFocused的等）到虚拟机带来的UI逻辑虚拟机，因为UI和表示逻辑混合是不是一个好的做法。

对于我来说，遵循模式是重要的，但更重要的是不要重复自己。我更喜欢绑定和代码隐藏中的几行，而无需将DataContext转换为具体的VM类型，调用VM的方法等。

不过，我不喜欢HolyWars，并承认由于误解了这两个术语以及相互分离的标准，我可能会错。

来源

2013-02-01 Pavel Voronin

http://en.wikipedia.org/wiki/Presentation_logic对我而言，演示文稿看起来像UI逻辑http://en.wikipedia.org/wiki/User_interface – kenny

我认为在VM中放置表示逻辑非常重要，并且在其上具有像IsEnabled这样的属性，因为这样可以测试它。这也降低了视图的复杂度，从而减少了无法进行单元测试的代码量。此外，我会对你的同事可能会有关于为什么虚拟机中的表示逻辑不是最佳实践的任何引用感兴趣。恕我直言，用户界面是表示层的一部分，虚拟机的目的是为视图建模。因此，在这里放置表示逻辑似乎很自然。

附加编辑：

从Implementing the MVVM Pattern

视图的责任是明确的用户在屏幕上看到什么样的结构和外观。理想情况下，视图的代码隐藏仅包含调用InitializeComponent方法的构造函数。在某些情况下，代码隐藏可能包含UI逻辑代码，这些代码实现了可扩展应用程序标记语言（XAML）中难以或低效表达的可视行为，例如复杂动画，或者代码需要直接操作视觉元素视图的一部分。你不应该在视图中放置任何你需要进行单元测试的逻辑代码。通常，视图代码隐藏中的逻辑代码将通过UI自动测试方法进行测试。

来源

2013-02-01 09:23:17

不确定是从VM控制选择还是焦点是一种演示逻辑。这就是为什么我要求澄清这些条款。 –

他们可能是对的。但我认为将这种逻辑放入虚拟机可以使测试变得更加简单。尤其是如果控制状态是由业务逻辑决定的。 –

@voroninp我同意大卫，像控制选择和焦点的东西是用户界面/表示逻辑。虚拟机用于“控制”域和UI之间的交互。他们是否建议将该代码放在视图本身中？ – kenny

演示逻辑vs UI逻辑

回答

相关问题