在公司实习了一段时间了，对于这样的service和dao的设计理解的不是很充分，希望有人能够解释一下：
为什么在dao的设计上会有一个BaseDao<T>的接口，里面定义了实体的一些基本的操作，然后会有一个BaseDaoHibernate<T>的实现类来实现BaseDao<T>接口并且扩展了HibernateDaoSupport ，最后其它的一些实体比如UserDao 等等都会像上图那样设计。
我目前是这样理解的，就是说有了一个BaseDao接口中定义了基本Entity通有的操作，然后BaseDaoHibernate 类实现了这些基本的操作，所以我们的其它实体UserDaoImpl 等等只要继承BaseDaoHiber类就不用把那些基本的操作再去实现一遍，这样简化了一些操作，然后就是在UserDao中我们可以增加某个实体特有的方法，让后再UserDaoImpl中去实现
至于Service也预留了接口，我理解的作用就是跟基本的面向接口编程差不多。
到底这样还有什么好处呢，希望有经验丰富的人能够讲解的详细一些，先谢谢各位了。
------解决方案--------------------
BaseDAO一般是提供从数据库 增加、删除、修改记录、查询所有记录、查询符合某个条件记录、取得某条记录等方法的底层数据操作自定义类。
由于我们可能操作多个数据库表，这样就需要为每个表提供一个操作他的类 xxDAO， 这些DAO继承BaseDAO 就可以省略很多重复代码（从数据库 增加、删除、修改记录、查询所有记录、查询符合某个条件记录、取得某条记录等方法的代码）...
然后因为DAO 与 Service分开 是因为， DAO是直接针对数据库进行操作的， 而Service是进行业务操作的，处理业务逻辑之用。
如：添加一个用户， DAO只需要用来向数据库插入用户记录，而Service考虑的是：插入用户，可能同时还需要添加 角色，可能还需要做其他业务操作等等...
其实现在市面上流行的 MVC模式 ，你可以去好好理解一下。 这样开发的好处就是层次清晰，使项目的扩展性更好...
------解决方案--------------------
service,例如银行一个转账的模式,你这边转出需要减金额,那边进账需要加金额,但是这个业务操作必须为一个操作体,所以一般就要在业务层声明一个事务去提交,.而dao层只会给你提供与数据库交互的功能
------解决方案--------------------
1你的问题可以拆分三个问题
一.继承问题。例如UserDaoImpl 等等只要继承BaseDaoHiber
这个楼上已经说了很多了。节省代码。（我就不详细说了）
2.面向接口编程
解耦合，方便维护，扩展.一种规范约束方便团队开发
范例：JAVA的JDBC，sun公司只写一个规范出来。你们数据库厂商自已去实现驱动。（规范约束）
3.mvc分层模式
区分层次的目的即为了“高内聚，低耦合”的思想。
有利于标准化，分层开发是为了把代码区分开来。放在一起多乱啊。也有一部分是为省代码的原因
补充一个例子：例如业务是转帐100块。手续费2块。这是业务问题。在SERVICE层写。从A去掉100块。B增加100百。去掉A的2元手续费。这是一个原子性的所以事务必须放在SERVICE.
楼主问题解决.
可以百度三层架构，面向接口编程，继承。问题解决