【发布时间】：2011-03-10 09:51:20
【问题描述】：
我对 MVVM 的感觉很复杂。看来我需要编写很多代码才能使最补救的事情发挥作用。我错过了事件（指挥是如此痛苦），绑定一切导致调试噩梦，我错过了对视图的引用！
我只是想知道您对 MVVM 与普通旧代码背后的方式的感受。您更喜欢什么和/或您通常使用或推荐使用什么？
谢谢
【问题讨论】：
标签： c# .net wpf silverlight mvvm
【发布时间】：2011-03-10 09:51:20
【问题描述】：
我在这方面绝对是少数，但我倾向于同意@Shnitzel。 MVVM 以及与之相伴的绑定是很棒的想法，但是当前的 MS 工具无法很好地满足它们。除了最简单的绑定之外，其他所有绑定的语法都很难正确，而且由于 WPF 和 Silverlight 默默地吞下所有错误，因此变得更加困难。 （是的，调试窗口中显示了一些错误，但还不够多，而且没有足够的细节。）您可以使用诸如编写调试值转换器之类的技巧，但事实仍然是该工具集仍然非常不成熟。 （然后是我的标准抱怨，数据绑定不是强类型的，这意味着工具无法为您捕获错误。）
我听到每个人都坚持可测试性，而且我是自动化测试的忠实拥护者。但至少在我们工具的当前状态下，MVVM 改进的可测试性付出了相当大的代价。
考虑这种情况：您有一个包含 50 多个表单/页面的大型应用程序，并且您刚刚对模型和视图模型进行了重大重构。在此过程中，您重命名了一堆类和属性等。现在在 XAML 中找到您需要更改以反映新的类和属性名称的每个位置。可测试性这么多，是吗？ IDE 不仅不会捕获您的绑定错误，编译器也不会捕获它们，而且最重要的是，应用程序甚至不会在运行时抛出错误。您必须让测试人员运行整个应用程序，并确保所有绑定仍在执行您希望它们执行的操作。哎呀。丑陋而痛苦。至少当我以老式的方式做事时，当我拼错某些东西时，编译器会告诉我。
回到我的山洞里躲避投石索和箭矢快速冲向我的方向……
[编辑 12/10/2010 - MS 最近宣布 SL5 将能够debug data bindings，包括在它们上设置断点的能力，所以你可以看到发生了什么。这是朝着正确方向迈出的一大步。它仍然没有解决我认为的根本问题，即数据绑定没有编译时类型检查，但它大大提高了工具集的实用性。]
【讨论】：
-
其实我很喜欢 wpf/silverlight 的绑定引擎。我会在代码后面使用绑定，所以它不仅仅是一个 mvvm 的东西。我的抱怨主要是无法轻松调用视图对象上的方法。
-
@Ken - 只是一个毡尖飞镖:-)。重构和调试 xaml is 比我想要的要痛苦得多，但是使用 mvvm 设计模式并没有真正引起问题。而我今天能想到的唯一选择是，如果您可以将更多的数据绑定从 xaml 中推到代码中，但代价是无法支持设计师。
-
我同意我概述的问题并不是 MVVM 模式固有的——只是在我们可以在 MS 堆栈上使用的唯一工具和框架中:-)。在我看来，根本问题是数据绑定没有强类型选项。只要您键入“{Binding...}”，您就可以在没有网络的情况下工作。 MS 的假设似乎是 GUI 很难，数据也很难，但是将它们连接起来非常简单，以至于您不需要任何工具支持来帮助您。这不仅是错误的，而且大错特错。
-
您刚刚解释了为什么我更喜欢 MVVM。后面有代码。如果您从提取界面开始，则可以根据自己的意愿进行重构，而根本不必触摸 UI。但是如果你把所有的代码都放在后面的代码中，它很快就会变成一团糟。
-
归根结底，Microsoft 需要改进其 MVVM 框架/visual studio 以完成事件处理等补救任务。程序员不应该将所有这些东西都挂在代码中。查看objective-c/iOS，视图与代码是分开的，但我不需要像在MVVM中那样写那么多垃圾。
人们提到了测试，这是一个很好的观点。 我认为的另一点是可重用性，将相同的视图模型绑定到不同的视图。例如，也许您对某些用户有一个简化的视图，而对其他用户有一个更高级的视图。
我看到人们提到处理事件是多么痛苦等等。有 MVVM 框架可以处理这个问题。在我看来，将事件处理程序挂钩到代码隐藏并从代码隐藏调用视图模型上的方法也是可以接受的。这肯定比不使用 MVVM 好，因为人们可能会遇到一些连接事件。
另一个巨大的优势在于 MVVM 的性质，GUI 和业务逻辑的分离。如果你和设计师一起工作，他们都在 XAML 世界里，谈论渐变、边框、阴影等等。当您使用单元测试时，程序员很乐意在您的 ViewModel 上编写代码。因此，当设计人员准备好原型时，只需连接命令和绑定即可。简单的 GUI 就绪 =)
【讨论】：
-
+1 可以为不同的视图使用同一个 ViewModel 真的是一件很实用的事情，为我节省了很多时间。
整件事，恕我直言，一堆超级技术营销炒作，从长远来看，除了推动开发到开发成本可以承受生产力损失的负担之外，没有任何目的......即，离岸。创建一个可以做任何事情的功能性 UI 简直是 S-L-O-W。好像所有应用程序都是简单的内容页面、购物车或数据网格。太糟糕了。所以——如果一个应用程序在几个发布周期内解决了一些错误，那么它是如此糟糕，我们将用它换取一个没有人可能理解端到端整体情况的系统。 .. 为了什么？可测试性？真是一堆废话。好像错误和修复的日子已经过去了？是的，对...我的测试说 2 + 2 = 4，因此我的应用程序没有错误。正确的。
迭代开发会回来的，记下我的话。一旦与生产某些功能相比，TDD 的真正成本变得更加明显，就需要尽快。
【讨论】：
-
Brian 我认为你在混合隐喻。我是一个非常小的团队的一员，我们构建了一个小型 MVVM 库，进行了一些阅读并在良好实践中相互教育。只要我们为我们所做的任何新应用程序注入一小部分设计开销，它们就会毫不费力地到位。如果您发现在向 VS 发送垃圾代码之前检查您的用例太困难，您可以随意连接一些事件，享受意大利面条的乐趣，并为我们很好地处理 winform。它又老又累，需要爱。
现在，这里有些人使用 MVVM 并且很好。 有些人没有，因为他们承担了大部分开发任务，并且没有与上述设计师、测试人员等一起参与一些大型项目。 但是，我两者都去过，也见过两种方式。有些人会跳入任何模式，无论如何都必须实施它。 即使是用于管理一些小数据的小型应用程序也在 MVVM 等中开发。尽管其中一些程序可能会在几天内被破解，但它们将被安排和计划数周，但必须完成模式和测试等等。 老实说：许多开发人员边做边学，其中一些模式非常令人难以抗拒，因为它们结合了如此多的模式和抽象编程技术。
【讨论】：
事实上，很多人不使用单元测试。然而，仍然有充分的理由使用 MVVM。我要指出的是，这会将业务逻辑排除在 UI 之外。此外，如果您有相似的视图，您可以为它们使用相同的视图模型。
我也喜欢我可以对 UI 做出巨大的改变，而不必触及我的逻辑。或者，我可以轻松添加更多逻辑，而无需触摸我的 UI。例如，我已从列表更改为组合框，而不必触摸代码。
至于指挥，这对我来说是很长一段时间内的难点。然后我在 MVVM Light 中发现了 RelayCommand。这样，设置一个使用命令触发的方法就非常简单了。就我个人而言，我几乎从不在命令中使用参数选项。我更喜欢只使用视图模型内部的状态。
【讨论】：
类似于 MVVM 的方法的实用性随应用程序的范围和复杂性而变化。一方面是“不是很复杂，不是很有用”，而另一端是“需要很多人年才能构建，没有像 MVVM 这样的东西是不可能的”。
可测试性与此密切相关 - 应用程序足够小且足够简单，以至于 MVVM 感觉有些过头了，而且应用程序也非常小和简单，以至于真正的单元测试覆盖率是可笑的。然而，现实世界通常是非常复杂的，这意味着现实世界的应用程序确实需要单元测试来保持质量，并且它们确实需要 MVVM 是可测试和可管理的。任何认为没有他们也能过得去的人，都是在消耗大量的能量，而需要的能量却很少。或者更糟糕的是，让严重的质量问题被其他东西掩盖。
【讨论】：
来自Josh Smith's article on MVVM：
除了 WPF（和 Silverlight 2) 制作 MVVM 的功能 一种自然的方式来构建 应用，模式也是 很受欢迎，因为 ViewModel 类是 易于单元测试。当一个 应用程序的交互逻辑存在 在一组 ViewModel 类中，您可以 轻松编写测试它的代码。在一个 感觉，视图和单元测试只是 两种不同类型的 ViewModel 消费者。有一套测试 应用程序的 ViewModels 提供 免费且快速的回归测试， 这有助于降低成本 随着时间的推移维护应用程序。
对我来说，这是使用 MVVM 的最重要原因。
以前，我会拥有将视图和视图模型混合在一起的控件。但是视图本质上将鼠标和键盘事件作为输入，将绘制的像素作为输出。你如何对类似的东西进行单元测试或集成测试？ MVVM 解决了这个问题，因为它将不可测试的视图与可测试的视图模型分开，并使视图层尽可能薄。
【讨论】：
MVVM 有它的痛点——比如命令所需的所有样板代码、混淆绑定语法以及需要关闭表单的极其愚蠢的黑客攻击。
-- 但是--
这都是由于缺乏一个好的框架 - this video 让我大开眼界，如果你选择了正确的框架，它可以自动处理所有令人讨厌的部分（如果你找不到编写自己的迷你框架来解决您的痛点的好框架比处理“裸”MVVM 更容易）。
看看那个视频，看看如何使用一个好的小框架，你可以用比替代方案更少的代码编写 MVVM 应用程序。
【讨论】：
-
您的链接似乎已损坏。 I think this takes you to the same place.