使用DDD澄清MVVM

18-11-29 banq
         

很多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上给出一个简单的例子