1

我有以下设计： 我的设计 我的设计 http://s15.postimg.org/3zha8rzqh/Design_Idea.png

我将在我的服务层（左侧服务）中有一个名为“ProductDTO”的类。

当调用“更新产品（ProductDTO）”操作合约时 - 它应该调用业务逻辑层中的“更新产品”功能。

在数据库（“数据访问层”）中有一个名为“Product”的实体，因为我使用 LINQ-To-Entities，所以那里还有一个名为“Product”的类。

我的问题是 - 我在哪里从 'ProductDTO' 翻译成 'Product' ？

我应该在服务层中有一个“Translate_ProductDTO_To_Product”功能吗？这似乎是最合乎逻辑的答案，因为这是唯一知道“ProductDTO”是什么的层。

但这意味着服务层还必须知道“产品”是什么，因此必须引用数据访问层组件。

这个对吗 ？

我认为服务层应该只引用业务逻辑层，业务逻辑层应该只引用数据访问层，而服务层应该对DAL一无所知。

4

2 回答 2

2

看来您的困惑可能源于假设Product数据层中的类实际上是Product实体。通常在域驱动程序设计中，您的业务实体存在/是业务逻辑层。通常这些类“不知道”持久性，这是数据访问层的责任（通常使用对象关系映射器框架）。

在实践中，您的服务将需要对域模型（业务层）和数据访问层的引用才能执行有用的工作。WCF 服务代码和数据访问层都应该依赖于域模型，但域模型不应该依赖于数据访问层或 WCF 服务代码。

于 2012-04-23T12:55:08.320 回答
1

将 DTO 映射到服务层中的域实体。您的服务层需要了解 DTO 及其映射到（和从）的实体。我强烈建议您使用像 AutoMapper这样的工具来进行映射而不是手工制作。您的服务层不应引用您的 DA 层（或程序集）。您的 BL 稍后将需要引用您的 DA 层来持久化实体。编辑：您的业务实体可能不应该在 DA 命名空间下。如果您使用 ORM 工具来生成它们，请确保将任何 DDD 逻辑放在部分类的另一半中。

于 2012-04-23T13:07:16.093 回答