c# - WPF/Silverlight 程序员 : Is MVVM Overkill?

Question

我对 MVVM 的感觉很复杂。看来我需要编写很多代码才能使最有效的方法发挥作用。我想念事件(命令是如此痛苦)，绑定(bind)所有东西会导致调试噩梦，我想念对 View 的引用!

我只是想知道您对 MVVM 与背后的普通旧代码的感受。您更喜欢什么和/或您通常使用或推荐使用什么？

谢谢

Answer 1

在这方面我绝对是少数，但我倾向于同意@Shnitzel。 MVVM 以及与之相辅相成的绑定(bind)是很棒的想法，但当前的 MS 工具无法很好地满足它们的需求。除了最简单的绑定(bind)之外，所有绑定(bind)的语法都很难正确，而且由于 WPF 和 Silverlight 默默地吞掉了所有错误这一事实而变得更加困难。 (是的，一些错误显示在调试窗口中，但数量不够，也没有足够的细节。)您可以使用 hack，例如编写调试值转换器，但事实是该工具集仍然非常不成熟。 (然后是我的标准提示，数据绑定(bind)不是强类型的，这意味着工具无法为您捕获错误。)

我听到每个人都坚持可测试性，而且我是自动化测试的忠实拥护者。但至少就我们工具的当前状态而言，MVVM 改进的可测试性付出了相当大的代价。

考虑这种情况:您有一个包含 50 多个表单/页面的大型应用程序，并且您刚刚对模型和 View 模型进行了重大重构。在此过程中，您重命名了一堆类和属性等。现在在您的 XAML 中找到您需要更改以反射(reflect)新类和属性名称的每个地方。这么多的可测试性，嗯？不仅 IDE 不会捕获您的绑定(bind)错误，编译器也不会捕获它们，而且最重要的是，应用程序甚至不会在运行时抛出错误。您必须让测试人员运行整个应用程序，并确保您的所有绑定(bind)仍在执行您希望它们执行的操作。呃。又丑又痛。至少当我以老式方式做事时，编译器会在我拼写错误时告诉我。

回到我的洞穴以避免弹弓和箭迅速向我袭来......

[编辑 12/10/2010 - MS 最近宣布 SL5 将有能力 debug data bindings ，包括在它们上设置断点的能力，这样你就可以看到发生了什么。这是朝着正确方向迈出的一大步。它仍然没有解决我认为的根本问题，即数据绑定(bind)没有编译时类型检查，但它大大提高了工具集的实用性。]