我总是使用DTO将我的观点与我的JPA实体分离.
除了列出的3个原因,我还可以添加以下内容.
> JPA通常在父和子之间有双向引用,其中一个是真实的(存在于DB中),另一个是合成的.序列化为JSON时,您只有父子关系,这是合成关系.
>如果直接反序列化为实体,则必须完全了解分离的实体和合并.如果您曾尝试合并大型循环实体图,您将知道这不是在公园散步.
>对于JSON视图,性能也很重要.如果您使用实体生成JSON,则必须加载所有列.使用投影通常更有效,并直接在DTO中选择所需的列.
>如果您有一个API,您可以将DTO放入一个单独的模块中,该模块可以作为其他人的依赖项重用,而您永远不希望使用实体类.
> JB Nizet提到了不变性,这也是一个好点.使用@JSONCreator你可以拥有不可变的DTO,它可以有一些优点 – 虽然大多数时候DTO不用于多线程上下文,因此不需要.
在我的项目中,我总是使用Lombok来生成访问方法,这意味着DTO通常只包含数据字段(有时输入DTO有验证器或实用程序方法).这使得它们非常容易创建/修改,并且易于与包含逻辑的类区分开来.与编写业务逻辑相比,创建DTO没有时间,因此实现这种解耦的成本非常低,而且老实说我相信这样可以更容易地阅读代码.