视图模型接口上的WPF属性？

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

让我先说一句，我绝对主张尽可能针对抽象/接口而不是实现进行编码

在WPF中，在视图中进行绑定时，实际上并不是针对viewmodel接口编写绑定。您实际上是在绑定viewmodel/datacontext的实现。我认为您甚至可以争辩说您是针对空白画布进行绑定的，因为视图实际上不知道它在运行时将绑定到什么

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

---

我希望这个问题有道理

IMHO，视图模型是视图的模型。90%的时候，他们很可能是1比1。。。有用的部分是将逻辑移回比XAML更易于测试的地方。它们一起构成UI，但UI行为与UI表示分离

---

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

---

我可能会在一个系统中使用ViewModel接口，在这个系统中，行为和视图状态根据某些业务标准有很大差异。例如，如果您的视图正在进行驾驶执照字段编辑，并且所需字段因州而异，则可以将单个复杂视图绑定到IStateDriversLicenseViewModel界面。正确的版本可以根据您正在处理的状态注入依赖项，并可以公开IsorgandorOrSectionVisible等属性，以允许视图反映正确的更改。然而，在这种情况下，我怀疑由用户控件组成的视图将减少维护中的问题和复杂性。

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

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

在实践中，我看到的典型场景是视图和视图模型以及视图和模型之间的紧密耦合。通常，由于视图是为满足特定的业务需求而设计的，因此视图模型是为适应视图而定制的，以方便视图的业务角色

同样，我们的应用程序中实际将底层模型调整为ViewModel的部分应该与我们的视图（至少是声明性表示部分）分开。因此，自适应通常由视图的命令实现捕获。因此，尽管视图的声明性方面不了解底层模型，并且是松散耦合的，但业务实现或视图的命令在视图和模型之间引入了紧密耦合。同样，这很酷，因为视图的唯一目的是以特定的方式利用该数据作为其业务的一部分

我也喜欢抽象，特别是接口编程、依赖注入[DI]和控制反转[IoC]。然而，当紧耦合有意义时，就像在MVVM中一样，那么抽象就过于复杂了

---

在我看来，紧耦合带来的简单性正是使MVVM在模型-视图-控制器[MVC]领域比它的同类更具吸引力的原因。

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

---

有时我确实会在视图模型类中使用接口，但只有在我需要定义那些不在模型中的类之间的交互时才使用。

“我不认为抽象有用”和“我怀疑由用户控件组成的视图在维护中会导致更少的问题和复杂性”-现场