应用错误收集

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

我们决定使用以下技术：EF4（真正的v2），Unity

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

问题＃1： DTO - 最佳做法

我有我的域对象（POCO类）。有几种方法可以实现这些类。

传统方法：创建POCO类，其中包含公共getter / setter，Validation和＆amp;适当的业务逻辑。还要创建DTO并使用映射技术来管理它们。（Automapper）
传统 - DTO：创建如上所述的POCO类，但是，使用您的POCO作为传输对象。我的理解是，业务对象不应该离开域。
混合：我偶然发现了一个有趣的blog post，其中作者创建了他的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。

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

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

回答1

DTO与DDD正交，因为它们在应用程序架构中的不同位置提供不同的用途。也就是说，DTO在域模型中没有位置，因为它们没有行为，因此会导致Anemic Domain Models。

具有持久性无知的POCO是可行的方法。杰里米·米勒有一个很好的article that explains this concept。

回答2

位于域模型之上的图层通常需要返回自己为相关目的量身定制的对象。

对于UI，MVVM模式运行得特别好。 This article为WPF引入了MVVM，但该模式也像ASP.NET MVC中的魅力一样。

对于Web服务，这是DTO模式适用的地方。 WCF数据合同是DTO，如果您想知道：）

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

回答3

IoC（实际上是：DI）越多越好，但有一件事你的问题让我感到震惊：DI容器应该只连接对象图，然后放弃。对象不应该依赖于DI容器。

有关详细信息，请参阅this SO answer。

N层开发中的DDD概念

1 个答案: