在MVVM中使用视图后代码作为视图模型是否合适?

MVVM模式的一个目标是将逻辑与用户界面分离。使用代码隐藏文件作为视图模型,将逻辑和用户界面放在一起。如果这不困扰你,你甚至不必使用MVVM。

事件句柄

当切换到m-v-v m时,我发现了一个意想不到的快乐,那就是我有更少的事件处理程序——相反,我有更多的触发器、数据绑定和操作。由于挂接事件和未能挂接事件是内存“泄漏”的一个巨大原因(例如,参考周期、通过事件处理程序连接在一起的不可见对象树等),我刚刚从我的发货过程中消除了一类错误。

代码隐藏被事件处理程序重新请求。IDE会自动为您生成它们。你只能勉强使用它们。m-v-vm打破了这个坏习惯。

交换GUI框架

不确定是否应该使用桌面clr中的wpf来构建GUI?还是Silverlight?还是ASP.NET?还是AJAX/HTML5?

如果您使用m-v-v m,那么您可以换掉用于创建视图的GUI库,这样做容易得多。如果您必须用新技术重写视图,视图模型(例如应用程序工作流)和模型将保持相对相同。您可能需要修改ViewModel,以考虑不同的导航或数据绑定技术,但大部分底层结构将保持不变。

MVVM背后的一个核心思想是可测试性。编写运行视图模型属性和方法的单元测试很简单。大多数视图模型都非常简单,您必须是一个非常专注的TDD极客才能做到这一点,但是有很多应用程序在UI中嵌入了足够的逻辑,您希望能够对其进行回归测试。

如果您将该逻辑嵌入到代码隐藏中,唯一可以测试它的方法是通过操纵UI。为uis编写自动化测试是一个困难的问题——困难到几乎没有人做。MVVM当然不能消除对UI测试的需求,但是它将手工测试人员通常会做的工作中的很大一部分分离出来,并将其放在一个易于机器测试的地方。

尽管在最终的产品中,视图到视图模型通常是一对一的映射,但您可能不希望在此文件中对视图模型进行编码有以下几个原因。

• 为了测试的目的,您可能希望在另一个视图模型中进行交换,从而拥有多个代码文件。
• 代码隐藏文件仍然可以用于呈现/查看逻辑(纯粹主义者除外),否则XAML将很麻烦或难以维护。在这种情况下,不希望在同一个文件中同时拥有视图和视图模型代码。

除了抽象和可测试性之外的另一个原因:在某些情况下,您可能希望灵活性具有指向同一个视图模型的多个视图。