jakarta-ee - 如何在 Java EE 中建模？

Question

比方说，我决定为我的企业应用程序使用 Java EE 堆栈。

现在，对于域建模(或:用于设计 MVC 的 M)，我可以安全地假设和使用哪些 API，哪些 API 应该远离……比如说，通过抽象层？

例如，

我应该继续调用 Hibernate/JPA API 来乱扔我的模型吗？或者，我应该构建一个抽象......我自己的持久层以避免针对这两个特定持久性 API 进行硬编码？ 为什么我问这个:几年前，有这个 Kodo API 被 Hibernate 取代。如果有人设计了一个持久层并针对这一层编写了模型的其余部分(而不是通过调用特定供应商 API 来乱扔模型)，那么它就可以(相对)轻松地从 Kodo 切换到 Hibernate 再到 xyz。

是否建议在域模型中积极使用持久性供应商提供的 *QL？我不知道由于大量使用类似 HQL 的语言而产生的任何实际问题(如性能、可扩展性、可移植性等)。 为什么我问这个:我想尽可能避免编写自定义代码，因为它可以通过比 SQL 更便携的查询语言来完成。

抱歉，我是这个领域的新手。我在哪里可以找到有关此主题的更多信息？

Answer 1

以下是我认为的传统观点:

项目中的实体构成域模型。它们应该是可重用的，而不是与持久性技术紧密耦合(稍后我会回来讨论紧密耦合与松散耦合)

业务层，使用领域模型，但也暴露服务和其他东西。

数据访问层负责将领域模型(实体)持久化到持久化存储中。

实体不应直接调用数据访问层。但是业务层将以某种方式加载和持久化域模型的实体。

如果您将其映射到 Java EE 技术，您通常会得到如下结果:

实体 --> 带有 Hibernate/JPA 注释的 POJO。请注意，注释并不意味着与 JPA/Hibernate 的紧密耦合，完全相同的 POJO 可以在没有 Hibernate 的其他地方使用。

业务层 --> Session EJB 或 Spring

数据访问层--> JPA/Hibernate

这是一个粗略的草图，有很多可能的变体。您可以明显地跳过 session EJB 并以另一种方式实现业务层。您也可以决定让业务层直接调用 JPA/Hibernate Session/EntityManager，在这种情况下 JPA/Hibernate 才是真正的 DAL，或者您可能希望将访问 Session/EntityManager 包装成所谓的数据访问对象(DAO) )。

关于 HQL，尽量坚持可移植的，如果您使用原生 SQL，请遵循 SQL-92 约定。如果事情变得复杂，也许可以引入 DAO。这样，您就知道存在 HQL 查询的唯一地方是在 DAO 中。您也可以先在 DAO 中“程序化”实现查询逻辑，如果遇到性能问题，可以使用更复杂的 HQL 查询重新实现。

编辑

关于您在评论中的问题:

业务层依赖于数据层。如果您希望业务层不依赖于 Hibernate/JPA，那么您的数据层需要将 Hibernate/JPA 抽象掉。如果您将 DAO 用于数据层，情况就是如此。 DAO 将是“Hibernate 之上的薄手写持久层”(用你的话来说)。在你的情况下，我会为所有实体引入 DAO。

您要问的是一个非常通用的设计问题。我无法为此给出明确的配方，也无法在一个答案中总结所有变体，因为这取决于具体情况。比如，我们目前还没有谈到事务的问题，你通常从业务层开始，但数据层必须意识到这一点。这通常取决于所使用的技术和您的要求。

不过，这里有一份您可能感兴趣的资源列表:书籍 Pattern of Enterprise Application Architecture ，书 Real World Java EE Patterns - Rethinking Best Practices ，书 Domain Driven Design更具体地说是模式 Data Access Object , Repository pattern , Open Session in View (如果是用于网络应用程序)，也许是 Anemic Domain Model .

编辑 2

好的，再来几句关于交易的句子:

事务在概念上应该在业务层进行管理；在一个工作单元中需要做什么才能保持一致的定义实际上取决于应用程序的逻辑。

使用 EJB3，可以使用注释和应用程序声明事务。服务器为您管理。见 this other answer我的更多信息。使用 Spring，您还可以声明性地标记事务，但我不知道详细信息。否则，您将需要自己开始/停止交易。无论您使用 JDBC 事务还是 JTA 事务，这都会略有不同。

事务还与 Hibernate/JPA 中的延迟加载有关。一个延迟加载的实体，确实只有在有当前事务时才能加载。如果事务在业务层终止，则返回到表示层的实体需要急切加载。

为了规避这个问题，Web 应用程序的流行模式是 Open Session in View ，我已经提到过。在这种情况下，表示层开始/停止事务(这在概念上有点错误)，但在延迟加载时工作得很好。