业务层代码复用的一点建议

    传统的编写业务层的service类是为每个实体对象生成一个DAO，然后再每个实体DAO对应的service类中注入DAO属性作为服务层组件。这样做代码的可读性很好，层次分明，逻辑清晰。是一种较好的设计方式。

    如果考虑到代码软件最本质的特征-复用。减少不必要的编写。我们可以充分考虑Java语言的特征，诸如反射、多态、继承，以达到最大程度的重构。

    由此，我们在编写DAO层代码时，可设计一个BaseDAO类，抽象出最顶层的公有行为。
   

public void save(Object entityObj);
    public void update(Object entityObj);
    public Object findById(Class cls, Integer id);
    public List<Object> findByProperty(String hql, Object property);
    public List<Object> findByHql(String hql, Object[] values);
    public List<Object> findBySql(String sql, Object property);
    public List<Object> findBySql(String sql, Object[] values);

    在业务层，编写服务组件时，也可以抽象出一个BaseService类，集合公有行为。
   

public class BaseService {
          private BaseDAO baseDAO;

          // setter method
          // 共有方法
    }

    其他业务层服务组件，可以

extends BaseService

达到公有复用。

    当然，配置文件需配置bean的父子关系.

   

<bean id="" class="" parent="BaseService"></bean>

    这当然只是一种很简单的方法，你也可以从中抽象和重构出更简单更短小的设计。

   看的出来,lz是个认真学习的好孩子

想起以前人们常讨论的 泛型...

感觉楼主理解的service没有真正做到service的职责。dao不应该与service存在一一对应的关系，否则你的service仅仅是dao的一层壳，没有太多存在的必要。service与dao应该是1对n的关系（n>=1）

传统意义上来将，BaseDao封装的Crud操作已经够用了，dao是很薄的一层，多个Dao注入service只会额外增加code负担

用泛型设计 应该会更好 ~呵呵

这只是技术的代码复用，没有考虑到业务逻辑上的代码复用。技术是死的，业务需求的变化才是要命的

想起了泛型  basedao  就用泛型来写  

且要写成抽象的

我自己就是这样做的，本着dao只做存储的思想
一个service对应N个dao

public interface IBaseDao {
	void saveOrUpdate(Object entity);
	
	@SuppressWarnings("unchecked")
	void saveOrUpdateAll(Collection entities);
	
	void delete(Object entity);
	
	<T> List<T> loadAll(Class<T> entityClass);
	
	<T> T get(Class<T> entityClass, Serializable id);
}

实现：

public class BaseDaoHibernateImpl extends HibernateDaoSupport implements IBaseDao {
	@Autowired
	public final void setupSessionFactory(SessionFactory sessionFactory) {
		setSessionFactory(sessionFactory);
	}

	@Override
	public void saveOrUpdate(Object entity) {
		getHibernateTemplate().saveOrUpdate(entity);
	}
	
	@Override
	@SuppressWarnings("unchecked")
	public void saveOrUpdateAll(Collection entities) {
		getHibernateTemplate().saveOrUpdateAll(entities);
	}
	
	@Override
	public void delete(Object entity) {
		getHibernateTemplate().delete(entity);
	}
	
	@Override
	public <T> List<T> loadAll(Class<T> entityClass) {
		return getHibernateTemplate().loadAll(entityClass);
	}
	
	@Override
	public <T> T get(Class<T> entityClass, Serializable id) {
		return getHibernateTemplate().get(entityClass, id);
	}
	
}

理想总是美好的.
当你发现这个Dao需要分页,这个Dao需要转换成Dto,这个Dao的查询需要equals,like,le,lt等等.
有50%的Dao需要上述功能,50%的Dao不需要,那你到底是在不在BaseDao实现这些方法还是抽象还是让子类实现.当业务逻辑越来越复杂以后你就发现突然间Dao被无限扩大不可控了.所以我个人认为还是把公有类写成Utils的形式而不是继承