剛開始使用的時候,感覺類型安全,同時可以減少不必要的類型強制轉換,還可以很方便的使用for/in的語法, 帶來很多方便,但是使用多了,覺得滿眼都是尖括號(<>)又感覺有點不太爽,代碼看得亂亂的,覺得付出代碼“亂”的代價,得到效益好像不太大。
但是後來通過不斷重構DAO代碼,發現巨大的好處了。覺得DAO的代碼不用以前那樣寫很多重複代碼了,可以把大部分代碼都轉移到BasDAO這個基類裏。而DAO實現類裏基本沒有什麼代碼的,有的就直接繼承BasDAO就可以了。DAO的接口還是要保留原來的樣子,就是對外該提供什麼接口還提供什麼接口,這有利於擴展,如果只是一個DAO接口需要的功能,可以直接在接口裏加一個聲明,然後在實現類里加一個實現,通過在這裏都是加一些邏輯處理,而且可以直接使用BaseDAO的方法進行持久化。而且BaseDAO裏的通常需要得到T.class, 可以參考:[url]http://grandboy.iteye.com/admin/blogs/434062[/url]
下面給一個演示例子:
public abstract class AbstractBasDao <T> {
static Logger logger = Logger.getLogger(AbstractBasDao.class);
private Class<T> entityClass = (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
public void deleteByIdList(List<String> idList) {
//實現略
}
public void deleteAll() {
//實現略
}
public void deleteById(String id) {
//實現略
}
public Object insert(T entity) {
//實現略
}
public T selectById(String id) {
//實現略
}
public List<T> selectByPage(PageBean page) {
//實現略
}
public List<T> selectByIdList(List<String> idList) {
//實現略
}
public void updateById(T entity) {
//實現略
}
}
BaseDAO接口:
public interface BaseDao<T> {
@Transactional
public Object insert(T o);
@Transactional
public void deleteById(String id);
@Transactional
public void deleteByIdList(List<String> idList);
@Transactional
public void deleteAll(); // Just for unit testing
@Transactional
public void updateById(T o);
@Transactional("readonly")
public T selectById(String id);
@Transactional("readonly")
public List<T> selectByIdList(List<String> idList);
}
直接對上一層提供服務的DAO接口如下
public interface AccountDao extends BaseDao<Account>{
//如果需要提供新功能就在這裏加方法聲明
}
接口實現如下:
public final class AccountDaoImpl extends AbstractBasDao<Account> implements AccountDao {
public void deleteById(String id) {
//這個方法加要加一些邏輯
//然後再調用基類的方法去持久化對象
super.deleteById(id);
}
}
是不是發現Dao沒有以前那麼多重複代碼了? 這可是巨大好處。以後寫DAO的代碼少了,自然維護的代碼量也就少了。可以把更多的精力放在業務邏輯上。