在哪里处理DTO< - >业务对象转换

时间:2013-08-15 09:56:45

标签: c# wcf architecture dto n-tier-architecture

我开发了一个包含以下图层的应用程序:

  • 基于流畅的nHibernate的数据访问层
  • 业务规则
  • 活动层(比业务规则更抽象并使用一些 商业规则)
  • 基于WCF的服务层,它将一些DTO发送到外部世界 并收到DTO。

所以当一些DTO回来时,我可以将DTO映射到服务层中的业务对象,并使我的应用程序与业务对象一起工作。在这种情况下,当较低层中的某些功能执行时,它不知道有关旧对象的任何事情,因此很难处理和验证状态更改,并且DTO适配器也存在类爆炸。 另一方面,如果dto映射到更高层的业务对象,当它被关闭时,较低层对所调用的服务一无所知,因此它们无法解释这个dto必须如何更改业务对象(1 DTO可能以不同的方式被不同的服务使用)

所以问题是什么才是真正的解决方案?

1 个答案:

答案 0 :(得分:2)

根据您的规范,我假设您的目标是基于DDD的实施

首先,一些假设可以帮助将其映射到更常见的术语:我假设您的“业务规则”层仅由您的活动层使用,因此可以视为域层的一部分。

您提到业务对象。我假设你有一个域层。这可能是您的“活动层”。这应该是知道如何更新对象并将它们返回到服务层的层。

服务层(或DDD术语中的“应用程序层”)应该映射DTO并调用域服务。 MS有一个不错的图表here。但基本上工作流程应该是:

  1. 将DTO发送到服务层
  2. 服务层调用DTO适配器以从DTO创建域对象/实体。
  3. 服务层调用域服务以执行业务逻辑(调用规则)
  4. 域业务因业务规则而更新域对象
  5. 持久层由域服务根据需要调用
  6. 域服务将更新的域对象返回到服务层
  7. 服务层将域对象映射回DTO并将其返回
  8. 这个主题当然有很多变化,但这应该是你的起点。