我开发了一个包含以下层的应用程序:
- 基于fluent nHibernate的数据访问层
- 业务规则
- 事件层(比业务规则更抽象并使用一些 业务规则)
- 基于 WCF 的服务层，向外界发送一些 DTO 并接收 DTO。
所以当一些 DTO 返回时，我可以将 DTO 映射到服务层中的业务对象，并使我的应用程序与业务对象一起工作。在这种情况下，当较低层中的某些函数执行时，它对旧对象一无所知，因此很难处理和验证状态更改，并且 DTO 适配器也会出现类爆炸。 另一方面，如果 dto 映射到较高层的业务对象，当它下来时，较低层对调用的服务一无所知，因此他们无法理解此 dto 必须如何更改业务对象(1不同的服务可能会以不同的方式使用 DTO)
所以问题是真正的解决方案是什么？
最佳答案
根据您的规范，我假设您的目标是 DDD基于实现
首先，一些假设有助于将其映射到更常见的术语:我假设您的“业务规则”层仅由您的事件层使用，因此可以被视为领域层的一部分。
您提到了业务对象。我假设你有一个域层。这可能是您的“事件层”。这应该是知道如何更新对象并将它们返回给服务层的层。
服务层(或 DDD 术语中的“应用层”)应该映射 DTO，并调用域服务。 MS有一个不错的图表here .但基本上工作流程应该是:
- 将DTO发送到服务层
- 服务层调用 DTO 适配器以从 DTO 创建域对象/实体。
- 服务层调用域服务来执行业务逻辑(调用规则)
- 域服务根据业务规则更新域对象
- 持久层由领域服务根据需要调用
- 领域服务将更新的领域对象返回给服务层
- 服务层将域对象映射回 DTO 并返回它们
这个主题当然有很多变体，但这应该是您的起点。
关于c# - 在哪里处理 DTO<-> 业务对象转换，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18250318/