绑定到Model或ViewModel

Question

我知道已经有关于该主题的问题,但其中的问题在某种程度上与其他问题有关,并没有提供确凿的答案.

特别是那里:问题1,问题2,当然还有问题3 所以请不要太快关闭这个问题.他们回答那里只是说"做这个,做那个"而不是为什么!

有些人否认需要a ViewModel并且说"标准"方式是直接绑定到模型.这是我否认并试图用技术论证来证明的.

从我在后台MVC,MVP,Presentation Model,它只是很自然地我使用ViewModel.也许我错过了一个重点？

所以对我来说,默认是绑定到a ViewModel,无论它Model是什么(无论它是否实现INotifyPropertyChanged).

我看到绑定到s的原因有几个ViewModel,包括(如此处提到的CodeProject和另一篇文章)

1.从视图中删除逻辑

• 使逻辑单元可测试
• 减少代码冗余(在需要时复制)

2.安全

• 该模型包含用户不得更改的属性
• 如果绑定到模型,则会发生自动但不需要的更新

3.松耦合

• 如果直接绑定到模型,则较低层和View之间将存在耦合
• 更改模型会导致所有视图中的更改
• 视图不依赖于任何给定的模型
• 可以使用EF,某些DSL,批处理文件等轻松生成模型

4.发展速度

• 您可以从Prototype ViewModel层次结构开始并绑定到该层次结构
• 如果模型仍在开发中,您可以从a开始 Prototype Model
• Model并且ViewModel可以开发testdriven,无论View
• 该View可完全由设计师,还是具有很强的设计背景开发商建

5.解决了"棘手的同步"问题

• 对于任何给定的"棘手同步"问题,有很多解决方案,例如
• AutoMapper
• 来自模型的事件系统(模型触发事件,ViewModel订阅)

6.整个项目的结构相同

• 有一些点需要ViewModel,比如SelectedItem
• 将Binding与Model和ViewModel混合是错误的
• 新鲜的开发人员很难弄清楚项目的结构
• 稍后开始带ViewModel时,无法绕过它是凌乱的

7.可扩展性

• 让我们定义:如果你不使用ViewModel,它不是MVVM
• MVVM可以很容易地被用于许多数据源,很多视图
• 如果发现任何性能问题:延迟加载和缓存都在ViewModel中

8.分离关切

• 掌握复杂性是软件中的主要问题
• ViewModels全权负责推动变革
• 将通知发送到视图就像将其推送到不同的进程或计算机一样容易
• ViewModel,而不是模型/数据源上的更改通知的View寄存器
• 数据源可以忽略向导致更改的ViewModel发送事件

相反,来自另一个线程的人转储了一些点,包括

1. 如果直接更新模型,则视图模型将不知道触发属性更改事件.这会导致UI不同步.这严重限制了在父视图模型和子视图模型之间发送消息的选项.

2. 如果模型有自己的属性更改通知,则#1和2不是问题.相反,如果包装器VM超出范围但模型没有,则必须担心内存泄漏.

3. 如果你的模型很复杂,有很多子对象,那么你必须遍历整个树并创建第二个对象图,它会遮蔽第一个.这可能非常繁琐且容易出错.

4. 包裹的集合特别难以使用.任何时候(UI或后端)从集合中插入或删除项目,都需要更新影子集合以匹配.这种代码真的很难搞定.

所以,问题是:绑定的默认方式是什么？为什么？

我是否会错过必须拥有ViewModel的点数？

是否有任何想要绑定到模型的真正原因？

最重要的是为什么,而不是如何.

Answer 1

视图模型通常包含的成员,其意在与视图(例如,像特性可使用IsSomethingSelected,IsSomethingExpanded,IsSomethingVisible,任何的实施ICommand).

你认为有什么理由将所有这些东西带入模特吗？当然不.这就是视图模型存在的原因.

Answer 2

所以,问题是:绑定的默认方式是什么？为什么？

一般来说,我认为拥有ViewModel并绑定它是默认设置.有一个原因是"ViewModel"存在并且是MVVM模式的一部分.

除了纯粹的数据之外,ViewModel还有其他原因.您还通常实现特定于应用程序的逻辑(即:不是模型的一部分,但在应用程序中需要).ICommand例如,任何实现都应该在ViewModel上,因为它与模型完全无关.

是否有任何想要绑定到模型的真正原因？

在某些情况下,它可能更简单,特别是如果您的模型已经实现INotifyPropertyChanged.降低代码复杂性是一个有价值的目标,具有自己的优点.