只公开域对象的优点

1. 您编写的代码越少，产生的错误也越少。
   • 尽管在我们的代码库中有大量（可争论的）测试用例，但由于从域到DTO或反之亦然的字段复制遗漏/错误，我还是遇到了一些错误。
2. 可维护性-减少锅炉板代码。
   • 如果必须添加新属性，则不必添加Domain，DTO，Mapper和测试用例。不要告诉我这可以使用反射beanCopy utils来实现，它违背了整个目的。
   • 我知道Lombok，Groovy和Kotlin，但这只会让我省却吸气剂的困扰。
3. 干燥
4. 性能
   • 我知道这属于“过早的性能优化是万恶之源”的范畴。但这仍然可以节省一些CPU周期，而不必每次请求至少创建（至少）一个对象（然后进行垃圾回收）

缺点

1. 从长远来看，DTO将为您提供更大的灵活性
   • 如果我需要这种灵活性。至少，到目前为止，我遇到的都是对HTTP的CRUD操作，我可以使用几个@JsonIgnores来进行管理。或者，如果有一个或两个字段需要使用杰克逊注释无法完成的转​​换，正如我之前所说，我可以编写自定义逻辑来处理该问题。
2. 域对象因注释而肿。
   • 这是一个有效的担忧。如果我使用JPA或MyBatis作为持久性框架，则域对象可能具有这些注释，那么也将有Jackson注释。就我而言，这不太适用，我使用的是Spring boot，我可以通过使用应用程序范围的属性（如

     mybatis.configuration.map-underscore-to-camel-case: true

     ，

     spring.jackson.property-naming-strategy: SNAKE_CASE

短篇小说
，至少就我而言，缺点并没有超过优点，因此以新的POJO作为DTO来重复自己毫无意义。更少的代码，更少的错误机会。因此，继续公开Domain对象并且没有单独的“
view”对象。

免责声明 ：这可能适用于您的用例，也可能不适用。此观察是根据我的用例（基本上是具有15ish端点的CRUD api）