Question

我正在阅读EJB 3.0上的this article，其中作者描述了一种体系结构，其中服务层通过作为无状态会话bean实现的DAO与实体进行通信。

我试图理解为什么我们需要这个额外的图层。为什么服务层不能直接与实体对话？我想到的一个想法是 - 易于测试。我们可以通过模拟DAO来轻松测试服务层。

这是唯一的原因，还是有其他原因？

Answer 1

我们的想法是将业务逻辑（或服务层）与实际的持久性策略分离。例如，您的实体可以存储在平面文件或数据库中。您应该能够在不影响业务层的情况下更改此持久性策略。

服务层通过DAO与实体进行通信

这句话有点暧昧。使用EJB 3.0，业务实体是POJO。业务层可以使用它们，也可以使用数据访问层。业务层“直接”与业务实体“对话”。但它也与数据访问层进行了对话。数据访问层负责主要加载和保存实体。

交易违约是另一个需要处理的问题。使用EJB 3.0，业务层可以独立于所选的持久性策略来取消事务。数据访问层和业务实体应该强制执行业务层的事务。

我们可以通过模拟DAO来轻松测试服务层。

是。可以使用模拟数据访问层来测试业务层。可以在没有业务层的情况下测试数据访问层。同样，这很容易，因为业务实体是可由任一层使用的POJO。数据访问层所需的信息是通过注释提供的，注释与业务层无关，但是从业务角度来看，不对业务实体的建模施加约束。

Answer 2

DAO是关于如何使用对象访问数据库的抽象。在DAO的最初实践中，首先出现了一个接口，用于定义您期望从数据库中执行的操作：

interface ModelDao {
  Model load(Long id);
  Long save(Model object);
}

哪种可以是通用的或以任何适合您设计的方式。除了接口的高度可测性之外，DAO模式还增加了另一个优势，即现在您可以使用不同的技术实现相同的DAO模式。随着时间的推移，您可能需要从EJB切换到Spring JDBC或任何其他更改。

发生这一切时，服务层仍然只能通过 DAO接口看到数据层。实现总是从服务层封装。此外，它还通过 mocking 等机制增加了服务层的可测试性。

如果服务层直接开始处理数据层，则意味着服务层变为特定于实现，这减少了模块化和关注点的耦合，使得仅为业务测试服务层变得更加困难逻辑。

最后但并非最不重要的是，虽然坚持原始做法总是最好的，但这取决于您的产品/项目的规模和意图采用这种方法。

Answer 3

我想到的一个想法是 - 易于测试

不，它不仅仅是为了便于测试DAO层。在这种情况下，DAO的目的是将关注点分开。

@ewernli和@nobeh已经解释了DAO层等的目的。我想补充一点，它是解决问题的方法之一。而在Java世界中，这种使用显式DAO层的方法已经存在了很长时间。可以实现替代方法。例如，在Ruby / RoR世界中采用ActiveRecord的情况。

为什么服务层不能直接与实体对话？

是的，您可以设计您的应用程序，使服务层直接与实体对话。有一些人主张反对DAO并建议使用Domain Driven Design。

我个人对于持久化的不同层次的想法有点令人讨厌。在您指出的方法中，实体（ies）仅仅充当数据结构或blob来存储信息（getter和setter）。在大多数情况下，他们不会添加业务逻辑。