使用DDD澄清MVVM

很多MVVM的问题通常是相同的：什么应该是模型，什么应该是ViewModel？我们不能真正责怪开发人员，因为在线参考文档不是很好，特别是 MSDN的 。对于大多数开发人员来说，简化说明是可以理解的。结果是过于简化的模式，不适合复杂的业务应用程序。

MVVM有许多相互矛盾的实现。多年以来，我将在这篇文章中描述一个有效的实施方案。

问题根源 

每个人都同意ViewModel定义：它是View的抽象。这种抽象让GUI更容易测试，我们不需要运行解决方案就可以单独测试ViewModel。它将UI设计与UI行为分离。

但是这个ViewModel抽象应该是什么，真的不清楚。通常，实现是一个ViewModel，我们在其中放置了太多的业务逻辑和一个简单的 POCO 模型（主要是因为 ORM ）。

在这种情况下，出现了一个问题：当我在一个ViewModel中只使用一个Model时，我是否需要一个ViewModel？难道我直接绑定模型并通知View是否更新了其中一个属性？

  DDD来救援

域模型是来自域驱动设计（DDD）的战术模式，它可以使模型适合MVVM。使用DDD，我们希望避免使用贫血 模型 ， 模型 可能是MVVM实现的内容。

ViewModel只是View的抽象，它操纵着业务逻辑所在的模型。

例如，ViewModel可以使用User来更改地址：

user.ChangeAdress( new Adress("3 route de tartampion", "6900", "Lyon", "France"));

如果我需要几个模型怎么办？

DDD的另一种战术模式可以帮助我们：领域服务，是我们管理域模型之间交互的地方。如果我们找不到更好的地方来为指定的用例提供业务逻辑，我们就会使用它。我们的ViewModel将操纵操作域模型的领域服务。需要多个模型的典型用例是验证。

例如，ViewModel可以使用购买服务来验证命令：

_buyingService.Validate(/*products to buy*/, /*current user*/)

如果我不了解/关心DDD怎么办？

只需用Model替换DomainModel这个词，用BusinessService替换DomainService。将 SRP 应用于设计类。

例如在C＃中，Model不应该是INotifyPropertyChanged，它是一个UI关注点。ViewModel负责在属性更改时通知View。

同样的想法，ViewModel不应该嵌入业务逻辑，因为它已经负责UI行为。 简单设计的简单规则

• View有责任向用户显示内容。我们不希望这里有任何行为。
• ViewModel有责任表示View的行为。我们谈论的是UI行为，而不是业务行为。
• 模型有责任封装业务逻辑，而不关心它的显示方式。这是我们放置业务行为的地方。
• 如果涉及多个模型以满足业务需求，则业务服务有责任封装给定用例的业务逻辑。

Github 上给出一个简单的例子