使用“香草”WPF (没有像Prism这样的MVVM框架)。
我首先要说的是,只要有可能,我绝对主张针对抽象/接口而不是实现进行编码。
在WPF中,当您在视图中进行绑定时,实际上并没有针对视图模型接口对绑定进行编码。您实际上是在绑定viewmodel/datacontext的实现。我想你甚至可以说你是在一个空白的画布上绑定,因为视图实际上并不知道它在运行时将绑定到什么。
那么,包含视图将绑定到无用抽象的所有属性的视图模型接口是吗?视图模型接口应该更精简,只包含更改状态(或处理命令等)所需的方法。
我希望这个问题是有意义的。:)
发布于 2010-02-26 23:30:51
您好,ViewModel是视图的一个模型。在90%的情况下,他们可能是1比1...有用的部分是将逻辑移回比XAML更可测试的内容。它们共同构成了UI,但UI行为与UI表示是分开的。
就我个人而言,我不使用ViewModel接口。在命令模式和WPF和Silverlight使用的松散绑定之间,我不认为抽象是有用的。
我可能会在行为和视图状态因某些业务标准而大不相同的系统中使用ViewModel接口。例如,如果您的视图正在进行驾照字段编辑,并且所需字段因州而异,则可以将单个复杂的视图绑定到IStateDriversLicenseViewModel界面。正确的方法可以是基于您正在处理的状态的依赖注入,并且可以公开像IsOrganDonorSectionVisible这样的属性,以允许视图反映正确的更改。然而,在这种情况下,我怀疑由用户控件组成的视图会减少维护中的问题和复杂性。
发布于 2010-02-26 23:50:03
抽象,即接口编程在松散耦合的情况下是有用的,也就是说,消费者和生产者之间需要一种实现无关的关系。
根据您对模型视图MVVM的解释,允许紧密耦合。
在实践中,我看到的典型场景是视图和ViewModel之间以及视图和模型之间的紧密耦合。通常,因为视图是为满足特定的业务需求而设计的,所以ViewModels被定制为适合视图,以促进视图的业务角色。
作为Ben Von Handorf suggests,我们应用程序中实际使底层模型适应ViewModel的那一部分应该与我们的视图分开,至少是声明性表示部分。因此,适配通常由视图的Command实现来捕获。因此,尽管视图的声明性方面不知道底层模型,并且是松散耦合的,但业务实现或视图的命令在视图和模型之间引入了紧密耦合。同样,这很酷,因为View的唯一目的是以特定的方式利用该数据作为其业务的一部分。
我也是抽象的粉丝,特别是接口编程、依赖注入DI和控制反转IoC。然而,当紧密耦合变得有意义时,就像在MVVM中一样,那么抽象就过于复杂了。
由于紧耦合带来的简单性,MVVM在模型视图控制器MVC空间中比它的同类产品更具吸引力。
发布于 2010-02-27 03:25:41
我认为,当您只打算创建一个实现接口的类时,定义接口通常是不明智的。它描述了我创建的每个视图模型类。而且视图无论如何也不能使用接口。
我有时会在视图模型类中使用接口,但只有在需要定义那些没有正确存在于模型中的类之间的交互时才会使用。
https://stackoverflow.com/questions/2342494
复制相似问题