如何在Java EE中建模？ [英] How to model in Java EE?

问题描述

假设我已经决定将Java EE堆栈用于我的企业应用程序。

现在，对于域建模（或：用于设计MVC的M），我可以安全地假设和使用哪些API，以及我应该远离哪些API ...比方说，通过一层抽象？

例如，

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




2. 建议您在域模型中积极使用持久性供应商提供的* QL吗？我不知道由于大量使用类似HQL的语言而产生的任何现实问题（如性能，可伸缩性，可移植性等）。 为什么我这样问：我希望尽可能避免编写自定义代码，这可以通过比SQL更便携的查询语言来实现。

抱歉，我是这个地区的新手。我在哪里可以找到关于这个主题的更多信息？

解决方案

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

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


• 业务层，使用域模型，但也暴露服务


• 数据访问层负责将域模型（实体）持久存储在持久存储中。

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

如果将其映射到Java EE技术，通常会得到类似的结果： p>

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


• 业务层 - >会话EJB或Spring


• 数据访问层 - > JPA / Hibernate

这是一个粗略的草图，有很多可能变种。您可以特别跳过会话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。

你所要求的是一个非常通用的设计问题。我不能给出明确的方法，也不可能在一个答案中总结所有变体，因为它取决于具体情况。例如，到目前为止，我们没有谈到交易问题，您通常从业务层开始，但数据层必须知道。这通常取决于所使用的技术和您的要求。

不过，这里是您可能感兴趣的资源列表：书籍企业应用程序架构模式，书真实世界Java EE模式 - 重新思考最佳实践，书领域驱动设计，更具体地说是模式数据访问对象，存储库模式， 在视图中打开会话（如果是网络应用程序），也许贫血领域模型。

编辑2

好的，还有一些关于交易的句子：

交易应在概念上在业务层进行管理;在一个工作单元中需要做的事情的定义是否一致，取决于应用程序的逻辑。

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

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

为了解决这个问题，Web应用程序的流行模式是在视图中打开会话，我已经提到了。在这种情况下，表示层启动/停止事务（在概念上略有错误），但在延迟加载时工作得很好。

Let's say, I have decided to go with Java EE stack for my enterprise application.

Now, for domain modelling (or: for designing the M of MVC), which APIs can I safely assume and use, and which I should stay away from... say, via a layer of abstraction?

For example,

1. Should I go ahead and litter my Model with calls to Hibernate/JPA API? Or, should I build an abstraction... a persistence layer of my own to avoid hard-coding against these two specific persistence APIs? Why I ask this: Few years ago, there was this Kodo API which got superseded by Hibernate. If one had designed a persistence layer and coded the rest of the model against this layer (instead of littering the Model with calls to specific vendor API), it would have allowed one to (relatively) easily switch from Kodo to Hibernate to xyz.

2. Is it recommended to make aggressive use of the *QL provided by your persistence vendor in your domain model? I'm not aware of any real-world issues (like performance, scalability, portability, etc) arising out of a heavy use of an HQL-like language. Why I ask this: I would like to avoid, as much as possible, writing custom code when the same could be accomplished via query language that is more portable than SQL.

Sorry, but I'm a complete newbie to this area. Where could I find more info on this topic?

解决方案

Here is what I believe is the traditional view:

• The entities in your project form the domain model. They should be reusable and not tightly coupled to a persistence technology (I'll come back later about tight vs. loose coupling)
• The business layer, uses the domain model, but also exposes services and other stuffs.
• The data access layer is in charge to persist the domain model (entities) in a persistent store.

An entity should not call the data access layer directly. But the business layer will, in a way to load and persist entities of the domain model.

If you map that to Java EE technologies you usually get something like:

• Entities --> POJO with Hibernate/JPA annotations. Note that annotations do not imply a tight coupling with JPA/Hibernate, the very same POJO could be used somewhere else without Hibernate.
• Business layer --> Session EJB or Spring
• Data access layer --> JPA/Hibernate

That's a rough sketch and there are a lot of possible variants. You can notably skip the session EJB and implement the business layer another way. You can also decide to have the business layer call the JPA/Hibernate Session/EntityManager directly, in which case JPA/Hibernate is really the DAL, or you may want to wrap access the Session/EntityManager into so-called Data Access Objects (DAO).

Regarding HQL, try to stick to what's portable, and if you use native SQL, follow SQL-92 conventions. If stuffs get complicated, maybe introduce DAOs. This way, you know that the only place where there are HQL queries is in the DAOs. You can also first implement the query logic "procedurally" in the DAO, and if you have performance problem, re-implement it with a more complicated HQL query.

EDIT

Regarding your questions in the comment:

The business layer depends on the data layer. If you want the business layer to not depend on Hibernate/JPA then your data layer need to abstract Hibernate/JPA away. If you use DAO for your data layer, that will be the case. The DAO will be the "thin hand-written persistence layer over Hibernate" (to take your words). I would introduce DAO for all entities in your case.

What your are asking is a pretty generic design question. I can not give a definitive recipe for that, nor possibly summarize all variants in one answer as it depends on case by case. For instance, we didn't spoke so far about the problem of transactions, that you usually start in the business layer, but that the data layer must be aware of. This typically depends on the technologies used and your requirements.

Still, here is a list of resources that you might be interested in: the books Pattern of Enterprise Application Architecture, the book Real World Java EE Patterns - Rethinking Best Practices, the book Domain Driven Design and more specifically the patterns Data Access Object, Repository pattern, Open Session in View (if it's for a web app), and maybe Anemic Domain Model.

EDIT 2

Ok, a few more sentences about transactions:

Transactions should conceptually be managed in the business layer; the definition of what needs to be done in one unit of work to be consistent depends indeed on the very logic of the application.

With EJB3, transactions can be declared with annotations and the app. server manages that for you. See this other answer of mine for more information. With Spring you can also mark the transactions declaratively, but I don't know the details. Otherwise you will need to start/stop the transaction yourself. This will be slightly different whether you use JDBC transactions or JTA transactions.

Transactions also relates to lazy loading in Hibernate/JPA. An entity that was lazy loaded, can indeed be loaded only if there is a current transaction. If the transactions is terminated in the business layer, entities that are returned to the presentation layer need to be eagerly loaded.

To circumvent this problem, a popular pattern for web applications is Open Session in View, which I already mentioned. In this case, the presentation layer start/stop the transactions (which is slightly wrong conceptually), but works just fine with lazy loading.

这篇关于如何在Java EE中建模？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！