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

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


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


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

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

如果将其映射到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.