Java EE 架构 - 在使用像 JPA 2 这样的 ORM 时是否仍然推荐 DAO? [英] Java EE Architecture - Are DAO's still recommended when using an ORM like JPA 2?

问题描述

如果我使用的是像 JPA2 这样的 ORM - 我的实体映射到我的数据库，我还应该使用 DAO 吗?似乎开销要大得多.

If I'm using an ORM like JPA2 - where I have my entities that are mapped to my database, should I still be using a DAO? It seems like a lot more overhead.

例如，我需要维护三个额外的包:

For example, I would need to maintain three extra packages:

1. 一个指定我的域对象(它几乎映射了我的实体对象):

1. One that specifies my domain objects (which pretty much map my Entity objects):

public class Employee {
    private String firstName;
    private String lastName;
    ...
    // Getters and setters
}

一个包含指定我的 DAO 方法的接口

One that contains interfaces that specify my DAO methods

public interface EmployeeDAO {
    public void addEmployee(Employee employee);
    public Employee getEmployeeById(long id);
    ...
}

一个包含实现我的 DAO 的会话 bean

One that contains session beans that implement my DAO's

public EmployeeJpaDAO implements EmployeeDAO {
    interface method implementations here
    ....
    private method that transform my Employee entity into my Employee domain object
}

现在，每次我需要执行新的 CRUD 操作时，都会增加很多额外的负担.

Now that's a lot of extra baggage to add every time I need to perform a new CRUD operation.

然而，我认为拥有 DAO 的好处是:

However the benefits I see from having a DAO is:

1. 您可以在内存中实现 DAO，以对您的服务层进行单元测试.这意味着您不需要访问数据库来测试业务逻辑，并且您可以确信您的对象将始终包含相同的属性值

1. You can have an in memory implementation of the DAO for unit testing your service layer. This means you don't need to access the database to test business logic, and you can be assured that your objects will always contain the same values for properties

将业务逻辑与数据库访问逻辑分离

It separates business logic from database access logic

不涉及实现 DAO 的选项是只在服务层使用实体对象和 EntityManager:

The option that doesn't involve implementing a DAO is to just use entity objects and EntityManager in the service layer:

@Stateless
public class EmployeeEjb {
    @PersistenceContext(unitName = "employee")
    private EntityManager manager;

    public Employee getEmployeeById(long id) {
        return manager.createNamedQuery(Employee.GetEmployeeById).getResultList();
    }
    ...
}

这里没有中间立场吗?有没有人遇到过一个架构或实现了一个架构，它满足我上面提到的 DAO 层的一些好处(最重要的是业务逻辑的单元可测试性)，但不涉及实现 DAO 层所涉及的所有开销?

Is there no middle ground here? Has anyone come across an architecture or implemented an architecture that meets some of the benefits of a DAO layer (most importantly the unit testability of business logic) that I mentioned above, but doesn't involve all the overhead involved to implement a DAO layer?

感谢您的任何推荐和/或建议！我真的很想知道有些人对此有何看法.

Thanks for any recommendations and/or suggestions! I'm really curious to see what some people have come up with in regards to this.

推荐答案

如果我使用的是像 JPA2 这样的 ORM - 我的实体映射到我的数据库，我还应该使用 DAO 吗?似乎开销要大得多.

If I'm using an ORM like JPA2 - where I have my entities that are mapped to my database, should I still be using a DAO? It seems like a lot more overhead.

是的.很明显，Java EE 不鼓励在使用 JPA 时使用 DAO 模式(JPA 已经提供了 Domain Store 模式的标准化实现，屏蔽它没有太大价值在 DAO 后面).在这种情况下，我发现 DAO 是反DRY.

It is. And clearly, Java EE doesn't encourage using the DAO pattern when using JPA (JPA already provides a standardized implementation of the Domain Store pattern and there isn't much value at shielding it behind a DAO). I find the DAO to be anti-DRY in such situation.

所以对于简单的情况(实际上，大多数情况)，我很高兴跳过 DAO，我对此没有任何问题.对于更复杂的情况(例如，在使用存储过程、平面文件时)，我会使用它.换句话说，这取决于JPA是否杀死了DAO?.另请参阅以下相关问题:

So for simple cases (actually, most cases), I happily skip the DAO and I have no problem with that. For more complex cases (for example when using stored procedures, flat files), I'd use it. In other words, it depends, as summarized in Has JPA Killed the DAO?. See also the related questions below:

• 我发现了 JPA 或类似的东西，不鼓励DAO模式
• 简单但很好的 EJB 模式
• 为可在线和离线使用的应用程序分离层的好策略是什么?
• 使用 JSF、JPA 和 DAO.没有春天?
• jpa2/eclipselink 合适的 DAO 结构是什么?

(...) 一个包含实现我的 DAO 的会话 bean

(...) One that contains session beans that implement my DAO's

Noooo，您当然不想将 DAO 实现为会话 Bean:

Noooo, you certainly don't want to implement a DAO as a Session Bean:

• 您不想创建与表一样多的(池化)会话 Bean(资源浪费很大)
• 您不想将 Session Bean 链接到任何地方，也不要重现过去的错误，这是众所周知的不好扩展的做法.

因此，如果您真的想要采用 DAO 方式并希望注入 EM，请将您的 DAO 实现为 Spring bean(在 Java EE 5 中)或 CDI 托管 bean(在 Java EE 6 中).

So if you really want to go the DAO way and want the EM to be injected, either implement your DAOs as Spring beans (in Java EE 5) or CDI managed bean (in Java EE 6).

您可以在内存中实现 DAO，用于对服务层进行单元测试.

You can have an in memory implementation of the DAO for unit testing your service layer.

如果你真的想做单元测试，模拟DAO/EntityManager，没有区别.如果您想进行集成测试，您可以配置 JPA 以使用内存数据库.所以最后，我只是不买这个论点.

If you really want to do unit testing, mock the DAO/EntityManager, there is no difference. And if you want to do integration testing, you can configure JPA to use an in memory database. So at the end, I just don't buy this argument.

将业务逻辑与数据库访问逻辑分离

It separates business logic from database access logic

老实说，我没有看到依赖 DAO 与实体管理器之间的大区别，我看不到 DAO 如何更好地"分离事物.再说一次，我不买这个论点.

Honestly, I don't see a big difference between relying on a DAO vs an entity manager, I don't see how a DAO separate things "better". Again, I don't buy this argument.

根据我的经验，更改底层持久性解决方案是一个非常特殊的事件，我不会为很可能不会发生的事情引入 DAO(YAGNI, KISS).

And to my experience, changing the underlying persistence solution is a very exceptional event and I'm not going to introduce DAOs for something that is very likely not going to happen (YAGNI, KISS).

这里没有中间立场吗?有没有人遇到过一个架构或实现了一个架构，它满足我上面提到的 DAO 层的一些好处(最重要的是业务逻辑的单元可测试性)，但不涉及实现 DAO 层所涉及的所有开销?

Is there no middle ground here? Has anyone come across an architecture or implemented an architecture that meets some of the benefits of a DAO layer (most importantly the unit testability of business logic) that I mentioned above, but doesn't involve all the overhead involved to implement a DAO layer?

我没有看到太多的中间立场，而且正如强烈暗示的那样，如果我觉得没有必要，我不会使用 DAO.正如我所说，如果您想真正对业务逻辑进行单元测试，请模拟 EntityManager.它对我有用，我很高兴编写更少的代码.

I don't see much middle ground and, as strongly hinted, I don't use DAOs if I don't feel the need. And as I said, mock the EntityManager if you want to truly unit test the business logic. It works for me and I'm happy to write less code.

• JPA/EJB3 杀死了 DAO
• DAO 并没有死——但它们要么崩溃，要么消失了
• ...最后，如果出现以下情况，您应该引入 DAO:

这篇关于Java EE 架构 - 在使用像 JPA 2 这样的 ORM 时是否仍然推荐 DAO?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！