数据源不会在不同版本之间更改的 DAO Factory 示例

Question

下图表示 DAO Factory 的结构，其 dataStorage 不会在不同版本之间更改：

我的问题是关于一个实现的例子。假设我们有两个不同的 DAOs

UserDAO

public interface UserDAO{
    //CRUD operations and something else
}

PaymentsDAO

public interface PaymentsDAO{
    //CRUD operations and something else  
}

现在我们有两个 DAO 的实现：

UserDAOImpl

public interface UserDAOImpl{
    DataSource dataSource;
    //Implementation of the operations
}

PaymentsDAOImpl

public interface PaymentsDAOImpl{
    DataSource dataSource;
    //Implementation of the operations
}

现在我们正在创建一个新的 class，名为 DAOFactory:

public abstract class DAOFactory{
    UserDAO userDAO;
    PaymentsDAO paymentsDAO;

    public abstract getUserDAO();
    public abstract getPaymentDAO();
}

那么，现在如果我们有一个 BusinessObject，比如 PaymentService，我们只需添加一个 DAOFactory 作为字段并正确使用它？但为什么我们需要将所有 DAO 封装到一个工厂中？如果我们只是将必要的 DAO 对象作为属性添加到 BusinessObject 中，会不会更简单？

Answer 1

使用依赖注入，您的服务具有最小的耦合性，并且不了解 dao 工厂。

    DaoFactory daoFactory = new RdbDaoFactory(dataSource);

    myPaymentService.setUserDao(daoFactory.getUserDAO());
    myPaymentService.setPaymentDao(daoFactory.getPaymentDAO());

将所有 dao 封装到一个工厂中为您提供了一个实例化它们的中心点，并且如果您的持久层发生变化，将来可以轻松切换。

关于在业务对象（而不是工厂）中使用 Dao 不是更好的最后一点是正确的，我希望我的示例能为您说明这一点。

Answer 2

通过将所有 DAO 封装在一个单独的工厂中，您可以让 BusinessObject 不必担心 DAO。

让我们假设一个 DAO 是一把锤子。

让我们假设另一个 DAO 是一把螺丝刀。

假设您的 BusinessObject 是一名制作桌子的木匠。

您的木匠不需要知道锤子或螺丝刀是如何制造的，也不需要知道制造它们的材料是什么，在某些时候他只需要

thatOneThingWhichScrewsTheScrewsIn()

或

thatOtherThingWhichCanBeUsedToDriveNailsIn()

当他需要这些时，他认识一个人。

这家伙会帮他找到他需要的东西。

这家伙就是工具人。

这家伙就是DAO工厂。

数据源不会在不同版本之间更改的 DAO Factory 示例

Example of DAO Factory whose datasource is not going to change across the different versions

java

dao