我的DAO开始看起来一样,建议一个补救设计模式?

时间:2010-01-13 07:11:32

标签: java design-patterns generics

我注意到有一个数据访问对象(DAO)接口和实现真的开始加起来:

public interface ForceDAO{
    public void store(Force force);
    public void delete(Long forceId);
    public Force findById(Long forceId);
    public List<Force> findAll();
    public void deleteAll();
}

我有这个相同的接口,我的每个实体类的实现。在我对重构感到疯狂之前,我想知道是否有任何建议模式适用于此处?我有一些自己的想法:

  1. 使用模板模式将所有样板代码分解出来,并在需要时委托给特定的DAO。这可能会减少代码,但我认为接口和类文件的数量是相同的。

  2. 使用泛型描述接口和实现,然后使用我需要的特定DAO参数化实现。再次,这将减少代码,但我认为文件的数量将保持不变。此外,我不确定这是如何工作的,因为我的仿制技术还不强。到目前为止,这是我的首选。是否有其他人使用类似的策略?

  3. 创建一个实现常用功能的抽象基础DAO类,然后使用更具体的DAO类扩展它以获取详细信息。这样可以省去创建这么多接口的麻烦,虽然DAO方法的名称不能特定于实体(例如我不能使用findDogById(),它必须只是findById())。

  4. 最后,因为在检索数据时可能涉及不同的访问方案(Hibernate,JPA,iBatis等),看起来交换实现似乎是可取的。这非常适合策略模式。

  5. 开发DAO的最优雅,最有效的方法是什么?哪种方法最有利于重用并最大限度地减少冗余?

2 个答案:

答案 0 :(得分:4)

您可以查看generic dao

答案 1 :(得分:2)

在您的情况下,我会查看是否存在可以轻松应用于问题的现有基于模型的代码生成系统。特别是如果你有50多个这样的课程要写。

Hibernate,JPA等也是很有吸引力的选择,特别是在你可以使用注释等来避免编写这些DAO类的时候。

我最后的回退是使用泛型和抽象基类的组合。