.net - N 层开发中的 DDD 概念

Question

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

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

我获得的信息量最有启发性，但是，在最佳实践中我还有几个问题:

问题一: DTO - 最佳实践

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

传统方法:创建包含公共(public) getter/setter、验证和适当业务逻辑的 POCO 类。还可以创建 DTO 并使用映射技术来管理它们。 (自动映射器)

传统 - DTO:创建如上所述的 POCO 类，但是，使用您的 POCO 作为传输对象。我的理解是业务对象永远不应该离开域。

Hybrid:我偶然发现了一个有趣的 blog post作者在其中创建了他的 POCO 对象和 DTO。在他的领域对象中，他创建了一个 DTO 实例。这使得可维护性更容易，因为您不会像 #1 那样复制您的属性。像这样:

公共(public)抽象类 POCOBase : ValidationBase, IPOCO 其中 T : DTOBase, new()
{

公共(public) T 数据 { 获取；放; }

公共(public) POCOBase()
{
数据 = 新 T();
}

公共(public) POCOBase(T dto)
{
数据 = dto;
}
}

公共(public)类 SomePOCO : POCOBase { }

公共(public)类 SomeDTO : DTOBase

{

公共(public)字符串名称 { 获取；放; }

公共(public)字符串描述{get;放; }

公共(public) bool IsEnabled { 获取；放; }
}

//例子
//POCOBase somePOCO = new SomePOCO();
//somePOCO.Data.Name = "blablabla";
//somePOCO.Validate();
//返回一些POCO.Data;

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

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

例如，假设我正在使用亚马逊的 API。我想在我的个人商店中添加一本书。如果我尝试添加一本书而不发送其 ISBN，该服务可能会返回某种包含验证结果错误的响应组。

我错过了什么吗？我的印象(至少来自 DDD “纯粹主义者”)认为 DTO 不应该包含业务逻辑。在我看来，DTO 没有提供足够的信息作为传输对象。要么，要么我需要一种封装 DTO 和验证结果的新型 Response 对象。

问题#3:多少 IoC 太多了？

在我看来，我应该遵循黄金法则:

"Identify the parts of the application that vary, and separate from those that stay the same."

对我来说，这在应用 IoC 方面是有道理的。为了减少依赖，我的表示层、业务逻辑层和数据访问层都通过 IoC 容器进行通信。我的应用层包含通用接口(interface)和抽象。比这更多地使用 IoC 似乎有点矫枉过正。我喜欢我可以创建模拟测试存储库这一事实 - 只需更改 Unity 的配置，我就可以使用 TDD。

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

Answer 1

我将尝试一次解决您的问题。

回答 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 数据契约(Contract)是 DTO，以防您想知道 :)

这将需要在服务接口(interface)和领域模型之间来回进行大量映射，但这就是您必须为 Supple Design 付出的代价。您可以找到 AutoMapper在这方面有帮助。

答案 3

IoC(真的:DI)越多越好，但关于你的问题的一件事让我印象深刻:DI 容器应该只连接对象图，然后让开。对象不应依赖 DI 容器。

见 this SO answer更多细节。