问题描述
我是（重新）设计的大规模应用，我们采用多层架构基于DDD。
我们有MVC与数据层（实施资源库），领域层（域模型和接口定义 - 仓库，服务，工作单位），服务层（实施服务）。到目前为止，我们使用的领域模型（主要是实体）翻过所有图层，而我们使用的DTO仅作为视图模型（控制器，服务返回的域模型（S）和控制器创建视图模型，这是传递给视图）。
我心中已经阅读使用，不使用，映射并传递DTO的无数文章。据我所知，没有任何明确的答案，但我不知道它是否可以或服务控制器不返回域模型。如果我回到域模型，它仍然没有传递到视图，因为控制器始终创建视图特定视图模型 - 在这种情况下，它似乎合法的。在另一方面，当领域模型离开业务层（服务层），它不适合我。有时，服务需要返回，这不是在域中定义的数据对象，然后我们要么有新的对象添加到未映射域，或者创建POCO对象（这是丑陋的，因为有些服务回报域模型，一些有效地返回的DTO）。
现在的问题是 - 如果我们严格使用视图模型，它是确定返回域模型一路控制器，或者我们应该始终使用的DTO与服务层的沟通？如果是这样，那是正确的依据是什么服务需要调整的领域模型？ （坦白说，我不这么认为，因为服务要消耗有什么域）。如果我们要严格坚持DTO的，应该他们服务层来定义？ （我是这么认为的。）有时候很明显，我们应该使用的DTO（例如，当服务执行大量的业务逻辑，并创建新的对象），有时很明显，我们应该只使用域模型（例如，当会员的服务回报贫血用户（ S） - 它似乎将没有多大意义创建DTO是相同的域模型） - 但我preFER一致性和良好做法
文章Domain VS DTO VS视图模型 - 如何以及何时使用它们（和一些其他物品）非常相似，我的问题，但它不回答这个问题（S）。文章Should我实现了与EF存储库模式的DTO？也类似，但它不会与DDD处理。
免责声明：我不打算使用任何设计模式，不仅是因为它的存在，是看中，在另一方面，我想用良好的设计模式和做法，还因为它可以帮助设计应用程序作为一个整体，与关注点分离帮助，甚至tohugh使用特定的模式是不是必要的，至少在那一刻。
和往常一样，谢谢你。
Makes you feel like you are pulling the guts out right? According to Martin Fowler: the Service Layer defines the application's boundery, it encapsulates the domain. In other words it protects the domain.
Can you provide an example of this data object?
Yes, because the response is part of your service layer. If it is defined "somewhere else" then the service layer needs to reference that "somewhere else", adding a new layer to your lasagna.
A DTO is a response/request object, it makes sense if you use it for communication. If you use domain models in your presentation layer (MVC-Controllers/View, WebForms, ConsoleApp), then the presentation layer is tightly coupled to your domain, any changes in the domain requires you to change your controllers.
This is one of the disadvantage of DTO to new eyes. Right now, you are thinking duplication of code, but as your project expands then it would make much more sense, specially in a team environment where different teams are assigned to different layers.
DTO might add additional complexity to your application, but so are your layers. DTO is an expensive feature of your system, they don't come free.
Why use a DTO
This article provides both advantage and disadvantage of using a DTO, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html
Summary as follows:
When to Use
- For large projects.
- Project lifetime is 10 years and above.
- Strategic, mission critical application.
- Large teams (more than 5)
- Developers are distributed geographically.
- The domain and presentation are different.
- Reduce overhead data exchanges (the original purpose of DTO)
When not to Use
- Small to mid size project (5 members max)
- Project lifetime is 2 years or so.
- No separate team for GUI, backend, etc.
Arguments Against DTO
- Duplication of code.
- Cost of development time, debugging. (use DTO generation tools http://entitiestodtos.codeplex.com/)
- You must synchronize both models all the time.
- Cost of developement: Additional mapping is necessary. (use auto mappers like https://github.com/AutoMapper/AutoMapper)
- Why are Data Transfer Objects an anti-pattern?
Arguments With DTO
- Without DTO, the presentation and the domain is tightly coupled. (This is ok for small projects.)
- Interface/API stability
- May provide optimization for the presentation layer by returning a DTO containing only those attributes that are absolutely required. Using linq-projection, you don't have to pull an entire entity.
- To reduce development cost, use code-generating tools
这篇关于如果服务总是返回的DTO，或者他们也可以返回域模型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！