关于Service和DAO层的功能划分的迷惑

目前我的BaseDao是这样的

public abstract class AbstractDao extends SqlMapClientDaoSupport {
	protected final static Log log = LogFactory.getLog(AbstractDao.class);

	public int updateEntity(Object entity, String statementId)
			throws Exception {
		return getSqlMapClientTemplate().update(statementId, entity);
	}

	public int insertEntity(Object entity, String statementId)
			throws Exception {
		return getSqlMapClientTemplate().update(statementId, entity);
	}

	public int deleteEntity(Object entity, String statementId) throws Exception {
		return getSqlMapClientTemplate().delete(statementId, entity);
	}

	public Object queryForObject(Integer pkid, String statementid)
			throws Exception {
		return getSqlMapClientTemplate().queryForObject(statementid, pkid);
	}

	public List queryForList(Object params, String statementid)
			throws Exception {
		return getSqlMapClientTemplate().queryForList(statementid, params);
	}
}

然后BaseService这样

public abstract class AbstractService extends AbstractDao {

}

省略Dao层!

这样写法的用意是怎样？
AbstractDao 为什么要 extends 一个 SqlMapClientDaoSupport ？
SqlMapClientDaoSupport是什么？
看代码还是太detail，没有办法overview,虽然从直觉上我觉得你现在这样做有些复杂了，但是还没有充分的直接的理由下结论。能否把架构图展示一下先？

SqlMapClientDaoSupport 是 org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
我的代码很复杂吗?可能我没有表述清楚.
所有的Service继承AbstractService,
所有的Dao继承AbstractDao,
CRUD的简单操作不用在Service和Dao层定义,简单的Query直接写在Service中.
复杂的逻辑如isChecked(),count等直接和业务逻辑相关又不是简单的CRUD操作,才放置在DAO中.

基于上面的讨论,可以归纳为三种实现方式

第一种:BaseService不需要继承BaseDao

各种query,update等操作在Service和Dao中都做声明。Service不需要同BaseDao偶合过紧密，这也是第一页代码的实现方式。

第二种:BaseService不需要继承BaseDao，退化使用Dao层

各种query,update等操作在Service做声明，在Dao层不作声明，既Service直接调用BaseDao的queryForList,queryForObject等方法,由Service确定statementid。

第三种：BaseService需要继承BaseDao，退化使用Service和Dao

各种query,update等无业务逻辑的操作既不在Service中声明，也不在Dao中声明，Controller直接构造参数，确定statementid，然后调用BaseService的queryForList,queryForObject等方法.

本来采用第一种方式实现，发现代码过于繁琐；
后采用第二种，发现仍有简化空间
目前采用第三种，Service和Dao中几乎不用写任何代码，实现为第一位，项目时间紧。

同意这种方式
我曾经在项目中这样用过

目前有一个想法，前面有人说过用DaoHelper，不过我比较不喜欢直接调用Helper类，因此有这样一个想法：

将DaoHelper注入到AbstractService 中，然后针对DaoHelper的每一个方法调用在AbstractService 进行代理，也就是说所有的操作都需要通过Service不可以绕行，而且这样也不需要Service继承Dao,Service继承Dao总是感觉很奇怪。

当然缺点就是对于每一个Service都需要注入这样一个DaoHelper。

我记得这个问题在阎宏在《java与模式》曾经讲过：要尽量使用合成/聚合，尽量不使用继承。
而在我们这个问题上刚好是最佳注脚

Dao跟service本身就不是在一个层次上 让他们继承实在有些牵强，而采用合成/聚合则使dao层和service层有更松散的耦合，所以就耦合性来讲 采用合成聚合方式更为合理。
但是采用合成聚合方式会在xxxService类中多出一个daoHelper对象，好像是增加了复杂度。

其实只要明白了这个道理就行了，怎么简单怎么来啦

偶尔翻到这儿,我的解决办法是

public class BaseService{
  protected BaseDAO baseDAO;

  protected void saveOrUpdate(Object a){
    baseDAO.saveOrUpdate(a);
  }
  //....
  //get/set dao
}

public class ConcreteService extends BaseService{
  
}


public class ViewBean{
	private ConcreteService service;
	private ConcreteModel model;
	public String save(){
		service.saveOrUpdate(model);
	}
	
	//...
	//get/set service
}

偶尔翻到这儿,我的解决办法是

public class BaseService{
  protected BaseDAO baseDAO;

  protected void saveOrUpdate(Object a){
    baseDAO.saveOrUpdate(a);
  }
  //....
  //get/set dao
}

public class ConcreteService extends BaseService{
  
}


public class ViewBean{
	private ConcreteService service;
	private ConcreteModel model;
	public String save(){
		service.saveOrUpdate(model);
	}
	
	//...
	//get/set service
}