MVVM在业务应用程序中的价值（以及当前的开发实践）

2年后，我仍在努力将MVVM作为生产工作软件的实用方法。在某些情况下，这很棒。我做了一个多线程应用程序，它控制着一条小型装配线，如果没有MVVM概念，那将是一场噩梦。从物理装配线中提取的内容几乎是毫无道理的。

但是，我的职业生涯主要围绕内部业务应用程序-规范和优化业务运营。在此类应用程序中，通常存在围绕CRUD和复合操作的业务领域。在LOB中，我的视图模型最终只是业务类方法的一个行包装函数的非常简单的集合，最后最终只会使最简单的任务（如显示消息框或打开窗口）复杂化。当人们对已经存在了数十年的Window.ShowDialog调用进行“依赖注入”和“消息提供程序”的长篇描述时，没有其他人会觉得奇怪吗？在堆栈溢出中还有多少其他问题要求对Winforms中极其简单的任务提供建议？

不要误会我的意思-我得到了MVVM，它对于大型团队进行横向包装和销售的软件包的水平开发具有无价的价值。对视图模型进行单元测试可以避免严重的RTM错误，从而节省数百万美元，而专门的UI开发人员可以提供丰富的体验。但是，当重新部署的成本最小并且所有企业需要支付的只是简单的工作软件时，为什么我的业务逻辑已经进行了单元测试时，为什么我应该花时间对简单的“包装” vm进行单元测试？这项业务真正可以花多少时间让我花在可爱的动画和配色方案上？初级开发人员还有什么要做的事情（在以前查看“ Save_Click”的保存功能中查找错误，

诚然，我真的很喜欢WPF的数据绑定。为了利用它，我将数据上下文设置为窗口本身，在该窗口中它可以访问业务类以及任何其他可观察的属性。是的，我这样做几乎破坏了所有的MVVM“规则”。但是至少我有简单的事件驱动代码，易于阅读，而且可以利用新的数据绑定和验证。问题出在设计师身上-我并没有使用太多，但希望现在可以在2012年更好地进行集成-设计师展示了窗口及其基类具有的数百个属性。

对于那些可以关联的人，您可以指出我的资源，书籍，甚至只是观点的改变而使之更容易被吞噬。我会再试一试MVVM，但是上一次我为担心依赖项注入只是为了显示来自VM的消息框而感到非常愚蠢，我不打算进行单元测试。即使我进行了单元测试，通过对那些令人恐惧的“紧密耦合”应用程序的编译时错误进行交易时测试，我们是否真的能获得更高的质量？

我知道一个答案是只停留在winforms中。但是，作为WebForms的最后支持者之一（我对Web开发的趋势有很多相同的批评），当我发现发现Microsoft认证途径中再也没有WebForms时，我感觉就像是恐龙。前进是唯一的选择，即使我不喜欢它也是如此。

我的观点是基于多年使用Winforms的经验，Winforms是“老式方式”，具有事件和代码隐藏功能。因此，我可以绝对肯定地告诉您，一旦您超越了最简单的应用程序，您的代码就会迅速变成一团糟。这是不可避免的，因为那是那时编写应用程序的方式。

Webforms相同，不同之处在于它带来了无状态系统（Web）上的有状态抽象的额外复杂性。正如Rob Conery所说：

WebForms是一个谎言。它被包裹在谎言酱中的欺骗包裹着，而谎言酱则呈现在盘子上，上面充满了转移和手脚的技巧。与Webforms无关，与Web无关-让它为您完成工作。

这是从使用dynamicC＃中的关键字和仅四百行代码编写了一个功能齐全的对象关系映射器的人那里获得的。当他权威地谈论某事时，我会听。

我当前正在使用的应用程序是Winforms应用程序，主窗体中有多个选项卡。我可以将表单动态加载到每个选项卡中。虽然我没有遵循MVVM或MVP（你可以用像图书馆这样一个），我也积极推动的代码，我能出到一个单独的程序的每一位，留下绝对需要运行表单只是代码。那里仍然有几百行代码，其中不包括包含表单的控件定义，属性和事件处理程序分配的部分类，但是我永远不必再碰它，除非我需要在表单中添加一些新内容。

我有一个静态方法，可以处理表单和键/值对的集合，它将（使用反射）自动将键与表单中的字段进行匹配，并用集合的值填充表单。我也可以做相反的事情，从表单的字段中获取键/值对的集合。整个过程大约需要二十行代码，但是每次使用它都是值得的，因为我不必为表单上的四十个控件编写四十个自定义赋值语句。

我可以获取该键/值列表，并将其序列化为XML，从而可以将其持久化到文件中。我还有其他表格可以处理常规的DTO，并将其字段映射到该表格。在Winforms的“大泥巴”风格中，所有这些都不可行。当使用足够的去耦时，这几乎是微不足道的。

这听起来很熟悉吗？这应该; 它本质上是穷人的数据绑定形式。

诚然，我真的很喜欢WPF的数据绑定。为了利用它，我将数据上下文设置为窗口本身，在该窗口中它可以访问业务类以及任何其他可观察的属性。

对你有益。它不必符合MVVM。但是请记住，创建了诸如MVVM之类的模式来帮助开发人员构建大型系统。 如果只需要显示一个对话框，则可能不需要所有的管道。

WPF等系统的部分复杂性是所有试图以通用方式解决特定问题的程序员库所固有的。 为此，您必须考虑程序员使用库的每种实际方式。这增加了复杂性，但是对于那些精心设计库的人来说，这也带来了一种以统一且一致的方式处理事务的哲学。

考虑一下John Resig的jQuery库：这是一个统一设计的本质，它隐藏了有关DOM的许多怪异细节，以及浏览器处理它的方式的变化。仅仅写几行Java代码更简单吗？有时。但是，以一致，统一的API编写jQuery代码的好处是，让下一个来的人更容易理解您所做的工作，并在需要时维护该代码。

我对“大应用程序”模型的实际经验是使用ASP.NET MVC。 与Winforms与WPF一样，ASP.NET与ASP.NET MVC相同。 当我在ASP.NET中工作时，我总是竭尽全力地按照自己的意愿弯曲它。ASP.NET MVC向您弯曲。使用是一种快乐。它产生了清晰，有条理的系统结构，使您可以完全控制应用程序和标记。您可以自由地使用Javascript，jQuery和CSS，而ASP.NET MVC则不为您所用。

我唯一的障碍是习惯它，并以自己的方式了解它。

进一步阅读
您应该学习Rob Conery的MVC