简化DAO设计的思想

当应用中需要使用到上十张表时，DAO的维护变得日益困难，主要表现在这几个方面：
1）dao类的繁多，很多设计都是一个entity对应一个dao
2）dao接口需要维护的method庞大。
3）业务逻辑改变时，dao需要同时修改两个类文件（接口和实现类）

出于上述问题，有必要从新设计dao包。要求
1）减少dao类的数目，dao包暴露的接口稳定且易于扩展新的查询。
2）减少dao接口的method
3）可以动态增加dao提供的数据访问逻辑，比如增加相应的查询实现等等

我的分析：
可以使用Criteria，NamedQuery来构造复杂的查询逻辑。
对于改动最多的read/find逻辑，可以作一个抽象设计，以提供动态增加的同时提供稳定的接口。
对于update,create,delete逻辑，dao的设计遵循原子操作的原则，不在这些接口中实现复杂的业务逻辑。总体来说，这些接口的改动很少，也很容易规范。

下面是一些设计的类代码：
[code="java"]
public interface QueryObject{
public void setNamedQuery(String qstring);
public Object query(Session session,Set parameterCollection);
public QueryCfg getQueryCfg();
public boolean validate(QuryCfg cfg,Set params) ;
public void setValidatable(boolean bool);
public booelan getValidatable();
}

public interface QueryCfg{
public List getParameterCfgs();
public String getName();
public void setName(String name);
}


public interface Parameter{
public ParameterCfg getParameterCfg();
public String getValue();

}

public interface ParameterCfg{
public int getOrder();
public void setOrder(int order);
public String getName();
public void setName(String name);
public Type getType();
public void setType();

}

public interface Type{
public static final String PRIMITIVE_TYPE="primitive";
public boolean isPrimitive();
public Class getObjectType();
public String getValue(Object o);
}



[/code]
上面这些基本接口便是组成我的dao包的设计基架。虽然与普通dao实现比较起来，这个设计多了许多复杂度，在项目初期也需要一定工作量来编码实现这些构架，但是当在项目进展到中后期时，这个设计已经显露了它优良的设计风格，它与普通DAO的设计相比较，有如下优点：
1）DAO的设计将会更加简洁，用一个DAO接口就可以实现所有entity的dao操作，可以动态扩展复杂查询。DAO设计：
[code="java"]public interface DAO{
// find 可以根据
public Object find(String namedQuery,Set parameters);
public Object createEntity(Object entity);
public Object updateEntity(Object entity);
public void removeEntity(Object entity);
}

//具体的实现可以整合到优秀的容器里面。比如spring
publi class DAOImpl{
//....
public Object find(String name,Set ps){
return (Object)getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) throws HibernateException {
return QueryLocator.getQueryObject(name).query(session,ps);
});

}
}
//其中QueryLocator的实现可以用Spring，PicoContainer等等。
[/code]

2）业务逻辑层依赖于一个较稳定的DAO接口，使得可以更独立更快速的进行开发。
在业务逻辑层，他们可以这样写代码：

[code="java"]public class YourBusiness{
public void doBusiness(){
Set parameters=new LinkedHashSet();
parameters.add("firstName","test");
parameters.add(2,"test2");
List users=(List)getDao.find("findUserWithFullName",parameters);

}
}[/code]
这里的代码依赖于一个稳定的DAO接口，而不需要先实现DAO修改，再回来做相应的业务实现。
3）可以支持参数检查，因为dao包的设计中加入了诸如ParameterCfg，QueryCfg等配置类，通过扩展这些抽象配置类实现我们定义的查询的配置，可以有效地帮助我们检查客户端的非法查询。
4）工作量统计。可以计算一下，dao增加一个新的复杂的查询，需要增加一个QureyCfg类(可选，如果queryObject支持验证参数，则需要否则不需要），一个QueryObject类，增加Spring的一个Bean配置。
传统的DAO设计的话，需要修改一个DAO接口，修改DAO实现。
传统的DAO设计对于增加或者修改查询接口的话，工作量稍微少于我的设计。
当系统的表为10个时，传统的DAo设计一般需要产生10个dao类（需要接口的话，为20个），如果一个dao类需要支持复杂的read查询为5个的话，对于查询的method，至少需要50个method实现。
而我的设计除去Type这个底层稳定构架层次以外，仅仅需要一个DAO实现类，如果尽量采用NamedQuery，那么整体QueryObject类实现一般仅仅需要10个左右即可，QueryObject还有利于抽象复杂的查询，甚至包括需要使用到Criteria的QueryObject实现。比如这么一个抽象：
[code="java"]public class CommonQuery implments QueryObject{
public Object query(Session session,Set parametes){
//验证参数合法性
if(getValidatable())
validate(getQueryCfg(),parameters);
List res = session.createCriteria(parameters.get("type"))
.add( Expression.eq(parameters.get("queryParam"),parameters.get("value")))
.list();
}
}[/code]
他可以抽象对某个表的某个字段等于某值的查询。
当然这些设计需要涉及到一个参数集合规范的问题，这些都是可以在项目初期很快设计明确下来以形成正式的QueryObject设计规范文档。

整体评估：
当应用中的entity数量极大时，这种dao的设计将大大优越于传统的dao设计。