我的通用DAO理解,请大家指正

service，action都可以 抛异常
一般service抛为主。

对于异常，在dao层显式抛应该没有太大的意义，因为底层数据库的操作，就算抛出了一场，上层仍然没法处理，顶多是告诉用户，后台数据操作错误。而service层是有必要显式抛出异常的，因为整个业务控制的逻辑在这里，哪些是正确的业务逻辑，哪些是错误的，对于程序开发人员是可以预知的。对于可以预知的错误，可以显示的抛出异，至于是checked，unchecked异常看具体情况了。

简单说就是，能够明确知道错误原因并且能够告诉用户做处理的，就抛出异常（unchecked，checked看具体情况）。不知道错误原因的，就不用显示抛出异常了，由上层异常捕获统一处理。

   思路不错，运用泛型也比较合理，只是API相对简单了些。建议楼主将DAO的接口行为分成三种：只读型，查询和普通。
   在楼主的generic dao中，查询功能较弱，并且没有区分read和readForUpdate两种行为（那么多用过ORM的人怎么没有一个谈到这两者的区别呢？呵呵...）。
   为了方便楼主理解，简单说明一下两者的区别，对于read，读取出来的对象如果被修改后，要调用相应的update(save)方法才能持久化。而readForUpdate则对于修改后的对象自动持久化。其实这个思想和原理最早来自于EJB的BMP与CMP（那些咒骂EJB的人其实应该学习学习的）。两者行为的区别对于系统的效率和性能来说是有着影响的

接口你可以参看 Nutz.Dao　的　接口定义 http://code.google.com/p/nutz/source/browse/trunk/src/com/zzh/dao/Dao.java

对于 BaseDao.save，如果是 public void save(Object entity)　会有啥不好呢？　如果是 Object，　你就不需要 BaseDao<T>　了吧，你的BaseDao　就不是泛型的了，只是某些函数是泛型的。　那么你就只要一份实现就好了，不需要我再提供实现类了。

如果你的 BaseDao　是泛型的 BaseDao<T>
那么 findById　就不需要第一个参数 entityClass　了

路过人士，说声悄悄话，看了这么多DAO，全部是基于spring的，既然有了强大的HibernateTemplate为什么还要费这么事呢