for*_*yez 7 .net c# silverlight wpf mvvm
我对MVVM的看法很复杂.似乎我需要编写如此多的代码来获得最有效的补救措施.我想念事件(命令是如此痛苦),绑定一切导致调试噩梦,我错过了对视图的引用!
我只是想知道你对MVVM的感受与背后的普通旧代码.你更喜欢什么和/或你通常使用或推荐使用什么？
谢谢
我绝对是少数人,但我倾向于同意@Shnitzel.MVVM以及与之相辅相成的绑定是很好的想法,但是它们很难被当前的MS工具所服务.除了最简单的绑定之外的所有语法都非常难以正确使用,并且由于WPF和Silverlight无声地吞下所有错误这一事实变得更加困难.(是的,一些错误出现在调试窗口中,但还不够,而且没有足够的细节.)你可以使用hacks来编写调试值转换器,但事实仍然是工具集仍然很不成熟.(然后是我的标准投诉,数据绑定不是强类型的,这意味着工具无法为您捕获错误.)
当他们坚持可测试性时,我听到了所有人,而且我是自动化测试的忠实粉丝.但至少在目前我们的工具状态下,MVVM的可测试性得到了提升,价格相当高.
考虑一下这种情况:你有一个包含50多个表单/页面的大型应用程序,而你刚刚对模型和ViewModel进行了重大的重构.在此过程中,您重命名了一堆类和属性等.现在找到XAML中您需要更改的每个位置以反映新的类和属性名称.可测试性如此之高,嗯？IDE不仅不会捕获您的绑定错误,编译器也不会捕获它们,最重要的是,应用程序甚至不会在运行时抛出错误.您必须让测试人员在整个应用程序中运行,并确保所有绑定仍在执行您希望他们执行的操作.Ugggh.丑陋而痛苦.至少当我以老式的方式做事时,编译器会告诉我何时拼写错误的东西.
回到我的洞穴,以避免吊索和箭头快速前进...
[编辑12/10/2010 - MS最近宣布SL5将具有调试数据绑定的能力,包括在其上设置断点的能力,因此您可以看到正在发生的事情.这是朝着正确方向迈出的一大步.它仍然没有解决我认为的基本问题,数据绑定没有编译时类型检查,但它提高了工具集的实用性.
人们提到了测试,这是一个好点.我认为另一点是可重用性,将相同的viewmodel绑定到不同的视图.例如,您可能对某些用户有简化的视图,对其他用户有更高级的视图.
我看到人们提到如何处理事件是一种痛苦等等.有MVVM框架可以处理这个问题.在我看来,将事件处理程序挂钩到代码隐藏的视图模型和调用Viewmlol上的方法也是可以接受的.它肯定比不使用MVVM更好,因为人们可能很难连接事件.
另一个巨大的优势在于MVVM的本质,GUI和业务逻辑的分离.如果你与设计师合作,他们都在XAML世界,谈论渐变,边框,阴影和什么不是.在您的同时,程序员可以通过单元测试快速编写ViewModel代码.因此,当设计师准备好原型时,只需要连接命令和绑定即可.简单的piecy GUI ready =)
小智 5
整个问题是,恕我直言,一堆超级科技的营销炒作,并且从长远来看,除了推动发展到开发成本可以承受生产力损失的负担之外,没有任何目的...即,关闭 - 岸.创建一个可以执行任何操作的功能UI是一种疯狂的SLOW.好像所有应用都是简单的内容页面,购物车或数据网格.太糟糕了.所以 - 如果一个有几个错误的应用程序在几个发布周期中被淘汰是如此糟糕,我们只需将其交换为一个没有人能够理解端到端整体情况的系统. .. 为了什么？可测试性？真是一堆完整的垃圾.好像错误和修复的日子是什么,消失了？雅,对...我的测试说2 + 2 = 4,因此我的应用程序没有错误.对.
迭代开发会回来,标记我的话.一旦TDD的真实成本与某些功能的生产相比变得更加明显,就需要尽快实现.