java - Java EE项目中的服务层是否有必要通过DAO层与实体进行对话？

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

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

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

最佳答案

DAO是有关如何使用对象访问数据库的抽象。在DAO的原始实践中，首先提供一个接口(interface)，该接口(interface)定义了您希望从数据库中获得的操作:

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

可以是通用的，也可以是适合您设计的任何方式。 DAO模式除了具有高度的可测试性接口(interface)之外，还增加了另一个优点，即您现在可以拥有使用相同DAO模式的不同技术。随着时间的流逝，您可能需要从EJB切换到Spring JDBC或进行任何其他更改。

尽管发生了所有这些事情，但是服务层仍然并且仅通过DAO接口(interface)看到数据层。始终从服务层封装实现。此外，它还通过诸如 mock 之类的机制提高了服务层的可测试性。

如果服务层直接开始处理数据层，则意味着服务层变得特定于实现，这不仅降低了模块化和模块化的关注，而且使仅针对业务逻辑的服务层测试变得更加困难。

最后但并非最不重要的一点是，尽管始终最好地遵循原始做法，但这取决于您的产品/项目的规模和意图采用该方法。

关于java - Java EE项目中的服务层是否有必要通过DAO层与实体进行对话？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10085532/