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层，有点不雅，不过综合来看这个还是可以或略，不要专牛角尖嘛 :)