从 DAO 实现访问外部源
考虑以下简单的 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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
数据访问对象往往遵循相同的结构和模式,因此您可能需要考虑创建一个封装此共享逻辑的更高级别的类。我将用一个示例来强调,请注意,我省略了接口,因为我很少发现它们在 DAO 级别有用。
基础 DAO 类:
假设的 Account 对象的派生 DAO
正如您所看到的,您大大减少了派生 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:
A derived DAO for a hypothetical Account object
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.