为什么JPA中有这么多接口？

在看看一些JPA代码，我看到：为什么JPA中有这么多接口？

public interface Dao<T extends DomainObject> 

public interface EventDao extends Dao<Event> - nothing added to Dao<Event> 

public abstract class AbstractDaoJPAImpl<T extends DomainObject> extends JpaDaoSupport implements Dao<T> 

public class EventDaoJPAImp extends AbstractDaoJPAImpl<Event> implements EventDao

为什么这些2个接口的需要？为什么不能简单地使用

public abstract class AbstractDao<T extends DomainObject> extends JpaDaoSupport 

public class EventDao extends AbstractDaoJPAImpl<Event>

我来自Ruby on Rails世界，事情似乎更简单。我很肯定这种Java方法有很多优点。我经常可以认识到什么时候应该使用一个接口，但有时候我会觉得Java开发人员的界面很疯狂。

来源

2011-11-18 Alexandre

您在混合使用JPA和DAO概念。 JPA！= DAO。它们可以一起使用，但通常JPA被视为DAO的替代品，因为JPA由*标准*支持。相关：http://stackoverflow.com/questions/3818589/java-ee-architecture-are-daos-still-recommended-when-using-an-orm-like-jpa-2 – BalusC

找出JPA本身是什么，并重新发布一个真正的问题 – DataNucleus

实际上，您需要一个DAO接口，以便您可以轻松切换到另一个实现（例如模拟单元测试的dao's）。你也可以很容易地做一些事情，比如使用switch dao实现，将负载测试结果与不同的dao集合或类似的东西进行比较......并且使用通用接口来避免将所有基本crud方法添加到所有非通用dao接口 –

JPA不需要这些接口。

您需要在JPA中唯一需要的是您的实体定义，包括映射到数据库的注释。而已。管理数据库连接和存储实体的EntityManager已经由JPA编写，您不需要所有这些接口和类。

它们可能是由开发人员编写的，认为它可以分离数据库层（以及由JPA提供给您的EntityManager）和应用程序的任何其他层。

如果这是好事还是坏事，是另一个话题...

来源

2011-11-18 17:17:01

使用的界面允许定义的合同。该合同在具体的EventDao类中实现。

使用这种DAO的业务服务通常会使用EventDao接口作为注入的依赖项。这样做有几个好处：

能够以轻松注入模拟EventDao执行单元测试服务
能够使用动态代理各地的具体实施加
- 声明式事务管理（尽管这是划分交易的服务，但您可以使用强制传播在代理中验证交易是否存在）
- 统计信息和性能收集
- 其他有用aspe cts ...

来源

2011-11-18 17:18:30

为什么JPA中有这么多接口？

回答

相关问题