【问题标题】:Should I pass in or encapsulate a connection in a DAO?我应该在 DAO 中传递或封装连接吗?
【发布时间】:2011-01-25 11:41:39
【问题描述】:

将连接封装在DAO内部更好,即让DAO创建或检索连接然后关闭,还是将连接传递到DAO并在DAO外部的代码中处理细节更好?

跟进:如果将连接封装在 DAO 中,如何管理关闭连接?

【问题讨论】:

    标签: language-agnostic persistence encapsulation dao


    【解决方案1】:

    DAO 应该执行 CRUD 操作并对调用者隐藏这些操作。所以你应该封装连接。

    另一方面,如果上层正在协调 DAO(例如事务),那么您也可以将连接传递到 DAO(并在您打开它的同一级别关闭它,而不是在 DAO 中)。

    底线是……这实际上取决于应用程序每一层的职责。调用者是否应该关心 DAO 在哪里检索数据?如果不是,则封装连接。

    【讨论】:

    • 我正在考虑创建一个工厂并让 DAO 调用它,这本质上是封装。
    • DAO 工厂用于生产具体的 DAO(实现)。我不确定我是否理解您所说的“创建工厂并让 DAO 调用它”的意思!
    • 对不起,我指的是连接工厂,不是 DAO 工厂。
    【解决方案2】:

    我想你已经回答了你自己的问题。基本设计模式解释了 DAO 应该创建/检索连接(例如通过工厂),并将这些连接隐藏在服务层类等任何调用者面前。

    http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

    您认为将其保留在外部有什么好处吗?

    【讨论】:

      【解决方案3】:

      从纯粹的可用性和标准的角度来看,我认为您希望 DAO 负责连接。这毕竟是数据访问的主要功能。

      考虑您的使用,您是否希望使用 DAO 的表示/业务层代码对数据库有足够的了解以创建连接以传递给 DAO?如果您需要移动数据库或重新命名它怎么办,此时封装连接非常好。

      使用管理自己的连接的 DAO 还可以更简洁地使用调用代码中的对象,从而提高整体可读性,IMO。

      【讨论】:

        【解决方案4】:

        我认为 DAO 的关键在于您可以在应用程序的其余部分不知道或不关心的情况下更换实现。我实际上已经在一个项目中做到了这一点。 DAO 接口保持不变,但连接细节发生了变化,因此您无法在外部看到它。

        【讨论】:

          猜你喜欢
          • 2010-12-18
          • 1970-01-01
          • 1970-01-01
          • 2015-09-10
          • 1970-01-01
          • 2011-04-14
          • 1970-01-01
          • 2014-01-28
          • 1970-01-01
          相关资源
          最近更新 更多