View模型接口上的WPF属性？

Question

使用“vanilla”WPF（没有像Prism这样的MVVM框架）。

让我先说一下，我绝对主张尽可能针对抽象/接口与实现进行编码。

在WPF中，当您在视图中进行绑定时，您实际上并未编写针对viewmodel接口的绑定。您实际上是绑定viewmodel / datacontext的实现。我认为你甚至可以争辩说你绑定了一个空白画布，因为视图并没有真正知道它在运行时会绑定什么。

视图模型接口是否包含视图将绑定到无用抽象的每个属性？应该查看模型接口更精简，只包含更改状态（或处理命令等）所需的方法。

我希望这个问题有道理。 ：）

Answer 1

恕我直言，ViewModel是View的模型。 90％的情况下，它们可能是1对1 ......有用的部分是将逻辑移回到比XAML更可测试的东西。它们共同组成UI，但UI行为与UI表示分离。

就个人而言，我没有使用ViewModel接口。在命令模式和WPF和Silverlight使用的松散绑定之间，我不认为抽象会有用。

我可能会在一个系统中使用ViewModel接口，其中行为和视图状态根据某些业务标准而有很大差异。例如。如果您的View正在进行驱动程序许可证字段编辑，并且所需字段因州而异，则可以为绑定到IStateDriversLicenseViewModel接口的单个​​复杂视图创建案例。正确的可以是基于您正在处理的状态的依赖注入，并且可以暴露像IsOrganDonorSectionVisible这样的属性，以允许视图反映正确的更改。但是，在这种情况下，我怀疑由用户控件组成的视图会导致更少的问题和更少的维护复杂性。

Answer 2

当且仅当需要松散耦合[即消费者和生产者之间的实现无关的关系]时，抽象[即接口编程]才有用。

根据您对模型视图ViewModel [MVVM]的解释，允许紧耦合。

实际上，我看到的典型场景是View和ViewModel之间以及View和Model之间的紧密耦合。典型的，因为View旨在满足特定的业务需求，ViewModel是根据View来定制的，以促进View的业务角色。

作为Ben Von Handorf suggests，我们的应用程序实际上将底层模型适应ViewModel的那部分应该与我们的View [至少是声明性的Presentation部分]分开。因此，调整通常由View的Command命令实现。因此，虽然View的声明方面不了解底层模型并且松散耦合，但业务实现或View命令引入了View和Model之间的紧密耦合。同样，这很酷，因为View的唯一目的是以特定方式利用这些数据作为其业务的一部分。

我也是抽象的粉丝，特别是接口编程，依赖注入[DI]和控制反转[IoC]。然而，当紧密耦合有意义时，就像它在MVVM中那样，那么抽象就是过度复杂。

IMO，紧耦合引入的简单性使MVVM在模型视图控制器[MVC]空间中对其表兄弟具有如此吸引力。

Answer 3

我认为，当你只创建一个实现它的类时，定义一个接口通常是不明智的。这描述了我创建的每个视图模型类。并且视图无论如何都不能使用接口。

我做有时会在视图模型类中使用接口，但前提是我需要定义那些没有正确存在于模型中的类之间的交互。