从 DAO 实现访问外部源

发布于 2024-12-26 02:30:20 字数 829 浏览 3 评论 0原文

考虑以下简单的 DAO 示例:

public abstract class DAOFactory
{
    public abstract AccountDAO getAccountDAO();
    public abstract MessageDAO getMessageDAO();

    public static DAOFactory getDAOFactory(int whichFactory)
    {
        // depending on whichFactory
        return new SpecificDAOFactory();
    }
}

public interface AccountDAO
{
    public void add(Account account);
    public void delete(Account account);

    public int authenticate(Account account); // another source!
}

public interface MessageDAO
{
    //other methods
}

除了 AccountDAO.authenticate() 之外,上述所有方法都必须使用相同的数据源来实现。

身份验证信息可在其他数据源处获得,并且应该可以依次插入(例如可以是 SQL、LDAP 等)。同时,认证数据源独立于DAO数据源,即whichFactory可以是A、B或C,认证源可以是X或Y。

从接口设计的角度来看,authenticate非常适合AccountDAO。但从实施的角度来看,我感觉不舒服。

什么是更好的设计来提供清晰的数据访问层接口和实现?

Consider following simple DAO example:

public abstract class DAOFactory
{
    public abstract AccountDAO getAccountDAO();
    public abstract MessageDAO getMessageDAO();

    public static DAOFactory getDAOFactory(int whichFactory)
    {
        // depending on whichFactory
        return new SpecificDAOFactory();
    }
}

public interface AccountDAO
{
    public void add(Account account);
    public void delete(Account account);

    public int authenticate(Account account); // another source!
}

public interface MessageDAO
{
    //other methods
}

All above mentioned methods have to be implemented using the same data source, except AccountDAO.authenticate().

Authentication information available at the other data source and should be pluggable in turn (e.g. could be SQL, LDAP, etc.). At the same time, authentication data source is independent from the DAO data source, i.e. whichFactory could be A, B or C while authentication source X or Y.

From interface design point of view, authenticate fits nicely into AccountDAO. But from implementation point of view I feel uncomfortable.

What would be better design which will provide clear data access layer interface and implementation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

彼岸花ソ最美的依靠 2025-01-02 02:30:20

数据访问对象往往遵循相同的结构和模式,因此您可能需要考虑创建一个封装此共享逻辑的更高级别的类。我将用一个示例来强调,请注意,我省略了接口,因为我很少发现它们在 DAO 级别有用。

基础 DAO 类

public class BaseDAO<T> {
    private Class<T> clazz;

    public BaseDAO(Class<T> clazz) {
        super();
        this.clazz = clazz;
    }

    public T find(Long id) { ... }

    public List<T> findAll() { ... }

    public T create(T entity) { ... }

    public T update(T entity) { ... }

    public void delete(T entity) { ... }
}

假设的 Account 对象的派生 DAO

public class AccountDAO extends BaseDAO<Account> {
    public AccountDAO() {
        super(Account.class);
    }

    public List<Account> findByAccountStatus(String status) { ... }
}

正如您所看到的,您大大减少了派生 DAO 中的代码量。通过此设置,您不需要使用工厂,只需直接初始化 DAO 即可。

至于你的第二个问题,我不会在 Account DAO 上放置验证方法。身份验证应该在更高的抽象级别进行处理(非常适合服务层),即使它最终从数据访问层检索一些信息。

Data access objects tend to follow the same structure and pattern, so you might want to consider creating a higher level class encapsulating this shared logic. I will highlight with an example, please note that I am omitting interfaces because I rarely find them useful at the DAO level.

Base DAO class:

public class BaseDAO<T> {
    private Class<T> clazz;

    public BaseDAO(Class<T> clazz) {
        super();
        this.clazz = clazz;
    }

    public T find(Long id) { ... }

    public List<T> findAll() { ... }

    public T create(T entity) { ... }

    public T update(T entity) { ... }

    public void delete(T entity) { ... }
}

A derived DAO for a hypothetical Account object

public class AccountDAO extends BaseDAO<Account> {
    public AccountDAO() {
        super(Account.class);
    }

    public List<Account> findByAccountStatus(String status) { ... }
}

As you can see, you greatly minimize the amount of code in derived DAO's. With this setup you do not need to use a factory, just initialize your DAO's directly.

As far as your second question, I would not place an authenticate method on the Account DAO. Authentication should be dealt with at a higher level of abstraction (fits very nicely in the service layer), even if it eventually retrieves some information from the data access layer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文