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时，我感觉就像是恐龙。前进是唯一的选择，即使我不喜欢它也是如此。