Vit*_*lij 14 wpf design-patterns mvvm
我最近开始使用MVVM模式.我有几个项目,我使用它和每个新项目,我开始看到它将适合在新项目中.
现在我开始问自己是否存在最好不使用MVVM的情况.或者它是一个很好的模式,你可以在任何地方使用？
您能否描述一下MVVM不是最佳选择的几种情况？
我可以想到两种不使用MVVM的情况.
一个是如果应用程序足够简单,我不需要在视图模型和模型之间分离.如果我实施INotifyPropertyChanged和一RelayCommand两个,它是否会使我的课程过多？如果没有,我可能会跳过创建单独类的步骤.或者我可能只是想要一个视图模型来模拟功能UI,并担心如果客户端咬人的话,实现实际的后端功能.
另一个是当我需要足够高的性能,并且视图中有足够的对象时,我需要编写直接操作WPF对象的代码.我确实没有对它进行基准测试,但我有理由相信通过迭代包含它们的数组并TranslateTransform直接修改它们来绘制1000个移动粒子(如果确实这是定位它们的最快方法)会更快而不是修改他们的基本属性和绑定做它.
如果它是一个在特定时刻不会被使用的工具,那么我只会不使用MVVM.
在许多"小"项目中,我已经开始没有,后来,我已经改为MVVM.它使IMO的项目更加清洁,并为我的所有项目提供了类似的结构.如果客户端有一个小请求,这可以帮助我快速更改一些老代码中的一些东西.我没有太多的时间让我定位.
另一个优点是更容易保持我的库清洁,因为我可以专注于一种技术,因此有更多的时间来维护和扩展.
这完全取决于您想做什么。
就像这些人所说的那样，如果您正在创建一个不需要大量测试等的小工具或项目，那么 MVVM 就有点大材小用了。
可以说，MVVM 的主要优点是它使代码单元可测试，因为它从视觉层中抽象出来。对于需要可靠且由客户等（而不仅仅是您自己作为最终用户）使用的大型项目，MVVM 是一个很好的设计模式。
我想简而言之 - 如果你只是创建一个小项目来搞乱，那么 MVVM 就像尝试用火箭筒杀死一只蚂蚁:)
| 归档时间： |
|
| 查看次数： |
4095 次 |
| 最近记录： |