Spring 实体应该在服务中转换为 Dto 吗? [英] Spring Entities should convert to Dto in service?

查看:19
本文介绍了Spring 实体应该在服务中转换为 Dto 吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对此问题发表评论后.我开始研究,但我仍然很困惑.
实体在返回控制器之前应该转换为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;
    }
}

在此示例中,您的存储库将在内部使用实体.没有其他层知道或使用这个实体!它们是这个特定层的实现细节.所以如果存储库被要求返回一个人",它对实体起作用,但它会返回一个域对象.因此,在需要更改实体的情况下,保存与 repo 一起使用的域层.正如您在名称的情况下看到的那样,域和数据库可能不同.虽然数据库将名字存储在名字和姓氏中,但域只知道一个名字.这是它如何存储名称的持久性的详细信息.

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 实体应该在服务中转换为 Dto 吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆