跨web应用程序的所有层使用实体对象是不好的做法吗？

Question

我正在开发一个使用分层架构的web应用程序。我有：

1. 应用层(控制器)
2. 服务层(服务)
3. 数据访问层(DAOs)

它连接到后端Oracle数据库。

我使用带有Hibernate的JPA作为实现。因此，我创建实体来建模关系数据库表的对象视图。

我的问题是..。在我的所有三个层中使用这些实体对象被认为是不好的做法吗？

我知道数据访问层至少需要使用它，但除此之外，服务和应用程序层还需要使用它呢？

我看到一些人在服务和应用程序层中使用do，他们在do和实体之间进行服务和数据访问层之间的转换。

只是想知道这方面的最佳实践是什么，最好的方法应该是什么？

Answer 1

您不应该在所有层中使用实体对象。通过在所有层中使用相同的对象，您可以在UI表单数据和数据库表之间进行紧密耦合。

如果要更改UI上的字段名，则需要修改表中相应的列。因此，建议DTO、VOs将数据从DAO传输到前端。使用市场上提供的不同类型的映射器。其中一个例子是orika mapper。

Answer 2

在某些情况下，数据对象与用户在屏幕上操作的对象完全匹配。另一方面，在某些情况下，用户根据业务逻辑对派生和/或影响多个对象的对象进行工作。许多报告应用程序都是后者的例子。

根据您的域和用户配置文件，匹配数据/UI对象的频率是高还是低。您应该在需要时定义单独的模型，并通过项目中的更改来支付维护它们的成本。因此，过分分离的模式是不好的做法。另一方面，如果您坚持在任何地方传递数据模型，则您的业务逻辑或UI代码可能不太清晰。

分离数据访问层对象和传递给用户界面的对象的决定也取决于所使用的工具。例如，在控制器以静态方式(*)序列化为JSON的情况下，可以选择为对象图的每个不同的树遍历(要使用)定义类。另一方面，在基于JSP的UI中，相同的对象可能是可用的。

(*)一个例子是jackson，它使用注释将对象(图)序列化成树的方式。有一些方法可以限制树状-useful来防止不必要的数据泄漏，但是在我遇到的情况下，它们的实用性和可维护性是有限的。