在MVVM中使用View Behind of View作为View Model是否可以？

Question

在关于MVVM的所有教程中，我看到文件后面的代码没有什么用处，因为我们试图在视图模型中移动所有逻辑。是否有任何具体原因我们不将Code Behind文件本身用作View Model？

我理解MVVM的优点，而不是代码背后的典型代码，包括事件和簿记，但我正在尝试探索在MVVM中使用代码的可能性。

好处是， 我可以将我的模型作为一个依赖属性，第二个绑定和两个视图之间的通信变得更容易，因为模型被绑定到处。剩下的就是命令，无论是在Code后面的视图中还是在单独的View Model中会有什么区别？

Answer 1

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

Answer 2

事件处理程序

切换到M-V-VM时发现的意外快乐是我有更少的事件处理程序 - 我有更多的触发器和数据绑定以及操作。由于钩住事件并且未能解开它们是导致内存“泄漏”的巨大原因（例如，引用周期，通过事件处理程序将不可见对象的树连接在一起等），我刚刚从运输过程中消除了一类错误。

背后的代码重新与事件处理程序相关。 IDE会自动为您生成它们。你们几乎都会使用它们。 M-V-VM打破了这个（非常糟糕的）习惯。

Answer 3

交换GUI框架

不确定是否应该使用Desktop CLR中的WPF来构建GUI？还是Silverlight？还是ASP.Net？还是AJAX / HTML5？

如果您使用M-V-VM，则可以更轻松地更换用于创建View的GUI库。如果您必须在新技术中重写View，ViewModel（例如应用程序工作流程）和Model将保持相对相同的可能性。您可能需要修改ViewModel以考虑不同的导航或数据绑定技术，但大部分底层结构将保持不变。

Answer 4

MVVM背后的核心理念是可测试性。编写单元测试可以直接执行视图模型的属性和方法。大多数视图模型都很简单，你必须是一个非常专注的TDD专家才能做到这一点，但是有很多应用程序在UI中嵌入了足够的逻辑，你希望能够对它进行回归测试。

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

Answer 5

虽然在最终产品中通常存在视图与视图模型的一对一映射，但有几个原因可能导致您不希望在此文件中对视图模型进行编码。

• 您可能希望交换另一个视图模型用于测试目的，因此具有多个代码文件
• 仍然可以使用代码隐藏文件（除了纯粹主义者）来渲染/查看逻辑，否则XAML会很麻烦或难以维护。在这种情况下，您可能会在同一文件中同时拥有视图和视图模型代码。

Answer 6

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