key words: DAO模式
今天在看一篇文章時提到了DAO，這個東西以前也經常接觸，突然想回顧一下，于是打開Appfuse里看看dao模式（記憶中appfuse里就是很多的dao）
截圖如下:
很清楚，左邊的部分是基礎模塊，原意是想讓右邊的DAO和實現能夠重用左邊的，可是我找了半天也沒看到需要重用左邊的東西，因為在client調用的所有方法中都是明確的getUser或removeUser,就是沒有getObject或者removeObject,那么不禁要問，左邊的基礎dao和它的實現還有什么意義呢？所以我的第一想法就是把左邊的去掉得了，還好，果然有支持我想法的做法，打開springside,我們看到如下的結構:
截圖2
這里的做法更厲害，連interface也不要了，不過效果確實是很簡潔，在bookmanager里完全重用了左邊的基本方法 ：
public?Book?get(Integer?id)?{
????????return?(Book)?super.get(id);
????}
????public?void?save(Book?book)?{
????????super.save(book);
????????logger.info("保存圖書.圖書詳情:"?+?book.toString());
????}
????public?void?remove(Integer?id)?{
????????super.remove(id);
????????logger.info("刪除圖書.圖書ID:"?+?id);
????}
這是一個更務實的做法，如果你的項目并不是那么那么的復雜完全可以這么做，當然要說其有什么缺點顯然和沒有了interface的天生屬性決定了的，不可強求，若你對測試隔離面向接口以及你能想到的所有關于interface的好處，那就用你自己的方式吧。
現在我在想一個問題，難道appfuse里的繼承的基本關于object的做法就沒有地方可用了么？
其時正好碰到java視線這一篇文章有點相關，你可以參考一下:
用DAO模式有什么好處？
ps:
以前是一個基本的dao,然后n個業務dao繼承于這個基本dao,現在提供一個通用dao,每個要用到的地方直接繼承用就是了，更務實了!
不過，有一個小小的瑕疵，就是對于service中類似getUserByName或者getPeopleByEmail方法中需要提供給dao一個sql語句，從mvc的角度看，在service中看到了db層，有點不雅，不過綜合來看這個還是可以或略，不要專牛角尖嘛? :)