问题描述
在对此问题.我开始研究，但仍然感到困惑.
实体在返回控制器之前应该转换为Dto吗?对我来说，这听起来并不实用.
After a comment of this question. I started to research but I am still confused.
Entities should convert to Dto before return to controller? To me it sounds not really practical.
推荐答案
我们正在谈论软件体系结构，并且一如既往，当我们谈论软件体系结构时，有一千种方法来做某事，并且对什么是最好的方法有很多看法. .但是没有最好的方法，一切都有优点和缺点.请记住这一点！
We are talking about software architecture and as always when we are talking about software architecture there are a thousand ways of doing something and many opinions about what is the best way. But there is no best way, everything has advantages and disadvantages. Keep this in mind!
通常您具有不同的层:
- 用于存储数据的持久层
- 用于处理数据的业务层
- 用于展示数据的表示层
通常，每一层都将使用其自己的对象类型:
Typically, each layer would use its own kind of objects:
- 持久层:存储库，实体
- 业务层:服务，域对象
- 表示层:控制器，DTO
这意味着每一层只能使用其自己的对象，而永远不会将其传递给另一层.
This means each layer would only work with its own objects and never ever pass them to another layer.
为什么?，因为您希望每个层都与其他层分开.如果要在控制器中使用实体，则演示将取决于数据的存储方式.真的很糟糕您的视图与数据的存储方式无关.它甚至都不应该知道或如何存储数据.
Why? Because you want each layer to be separated from the other layers. If you would use entities in your controller, your presentation would depend on how your data is stored. That's really bad. Your view has nothing to do with how the data is stored. It shouldn't even know that or how data is stored.
考虑到这一点:您更改了数据库模型，例如您将一个新列添加到您的数据库表之一.如果将实体传递给控制器(或更糟糕的是:控制器将其公开为JSON)，则数据库中的更改将导致演示文稿发生更改.如果将实体直接公开为JSON，这甚至可能导致JavaScript或其他使用JSON的客户端发生更改.因此，对数据库进行简单的更改可能需要更改JavaScript前端，因为您将各层紧密耦合在一起.您绝对不希望在真实的项目中那样.
Think of that: You change your database model, e.g. you add a new column to one of your database tables. If you pass the entities to your controller (or worse: your controller exposes them as JSON), a change at the database would result in a change in your presentation. If the entities are directly exposed as JSON, this might even result in changes in JavaScript or some other clients which are using the JSON. So a simple change in the database might require a change in the JavaScript front end, because you couple your layers very tight. You definitely don't want that in a real project.
如何?您怀疑这是切实可行的，因此仅是一个小示例(伪代码):
How? You doubt that this is practical, so just a small example of how to do that in (pseudo) code:
class Repository {
public Person loadById(Long id) {
PersonEntity entity = loadEntityById(id);
Person person = new Person();
person.setId(entity.getId());
person.setName(entity.getFirstName + " " + entity.getLastName());
return person;
}
}
在此示例中，您的存储库将在内部使用实体.没有其他层知道或使用此实体！它们是此特定层的实现细节.因此，如果要求存储库返回人员"，则该存储库将在实体上工作，但它将返回域对象.因此，在需要更改实体的情况下，可以保存与存储库配合使用的域层.如您所见，在名称的情况下，域和数据库可能会有所不同.虽然数据库以名字和姓氏存储名称，但是域仅知道一个名称.这是持久性如何存储名称的详细信息.
In this example, your repository would use entities internally. No other layer knows or uses this entities! They are an implementation detail of this particular layer. So if the repository is asked to return a "person", it works on the entity, but it will return a domain object. So the domain layer which works with the repo is save in the case the entities need to be changed. And as you can see in the case of the name, the domain and the database might be different. While the database stores the name in first name and last name, the domain only know a single name. It's a detail of the persistence how it stores the name.
控制器和DTO只是另一层.
The same goes for controllers and DTOs, just another layer.
这篇关于Spring Entries应该在服务中转换为Dto吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！