N层开发中的DDD概念

Question

在花了几个月研究DDD方法之后,我现在开始将这些概念应用到我公司的实际产品中.事实上,我的任务是为未来的开发创建一个合适的,可维护的架构.

我们决定使用以下技术:EF4(真正的v2),Unity

我获得的信息量最具启发性,但是,我在最佳实践中留下了几个问题:

问题#1: DTO - 最佳实践

我有我的域对象(PO​​CO类).有几种方法可以实现这些类.

1. 传统方法:创建包含公共getter/setter,Validation和适当业务逻辑的POCO类.还要创建DTO并使用映射技术来管理它们.(Automapper)
2. 传统 - DTO:创建如上所述的POCO类,但是,使用您的POCO作为传输对象.我的理解是业务对象永远不应该离开域.
3. 混合:我偶然发现了一篇有趣的博客文章,其中作者创建了他的POCO对象和DTO.在他的域对象内部,他创建了一个DTO实例.这样可以更轻松地维护,因为您不会像#1那样复制属性.像这样:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

问题2: UI /服务层应返回哪些对象？

这是DTO的重点.一个非常简单,轻量级的对象,只包含裸属性.它也没有包含任何验证结果.如果我将我的DTO序列化回客户端,则应假定客户端需要任何验证结果,如InvalidRules集合.

例如,假设我正在使用亚马逊的API.我想在我的私人商店添加一本书.如果我尝试在不发送ISBN的情况下添加书籍,该服务可能会返回某种包含验证结果错误的响应组.

我错过了什么吗？我的印象是(至少来自DDD"纯粹主义者")DTO应该不包含业务逻辑.在我看来,DTO没有提供足够的信息作为转移对象.或者我需要一种新的Response对象来封装DTO和验证结果.

问题3: IoC多少钱？

我觉得我应该遵循黄金法则:

"确定应用程序中不同的部分,并与保持不变的部分分开."

对我来说,这在应用IoC方面是有意义的.为减少依赖性,我的演示文稿,业务逻辑和数据访问层都通过IoC容器进行通信.我的应用层包含通用接口和抽象.使用IoC似乎有点过分了.我喜欢这样一个事实:我可以创建模拟测试存储库 - 通过简单地改变Unity的配置,我可以使用TDD.

我希望我已经清楚地说明了这些问题.感谢您的帮助!

Answer 1

我会尝试一次解决你的问题.

答案1

DTO与DDD正交,因为它们在应用程序架构中的不同位置提供不同的用途.也就是说,DTO在域模型中没有位置,因为它们没有行为,因此会导致贫血领域模型.

持久性无知的POCO是可行的方法.Jeremy Miller有一篇很好的文章解释了这个概念.

答案2

位于域模型之上的图层通常需要返回自己的对象,这些对象是为相关目的而定制的.

对于UI,MVVM模式运行得特别好.本文介绍了WPF的MVVM,但该模式也像ASP.NET MVC中的魅力一样.

对于Web服务,这是DTO模式适用的地方.WCF数据合同是DTO,如果你想知道:)

这将需要在服务接口和域模型之间来回进行大量映射,但这是您必须为Supple Design支付的价格.您可能会发现AutoMapper在这方面很有帮助.

答案3

IoC(实际上是:DI)越多越好,但有一点关于你的问题让我感到震惊:一个DI容器应该只连接对象图,然后放弃.对象不应该依赖于DI容器.

有关详细信息,请参阅此SO答案.