一次关于简化DAO设计的初步思考！

我大致看了一下。

你真的觉得是类似的吗？ 是不是我说不懂 hibernate 和 jdo，所以没有认真看过？

不好意思，你只有代码，没有任何解释，可能是我误解了你的意思，我以为你想用面向对象的方式直接操作数据库。

呵呵，你没有误解。不过，squiggle 的形式跟我想表达的不一样，在我看来，这个不一样的地方才是重点，可能会因此带来不少好处。

我的注释很简单，不过，给出的代码形式应该已经比较清楚的表达了我想表达的东西。注释并不是越多越好，注释过于繁杂能会导致注释和代码不一致的情况。

DAO层还可以封装很多东西，不是简单的一个数据存取，譬如我们希望做自己的缓存，一个简单的例子例如我有一个分类树，/level1/level2/level3/，下面还可以有页面（页面可以是多级的）page1.page2.page3，在Web层可以输入
/level1/level2/level3/page1.page2.page3得到这个页面的内容，现在如果要构造这个查询语句的话就非常复杂，需要动态产生，执行的效率极低，如果是一个getPage(categoryKey,pageKey)那么我就可以在中间加入一个cache，采用编程方式也好，或者用AOPcache拦截也好，得到这个page的id，然后用getPageById(id)把他取出来。

当然这一层放在Service也可以，但这个方法可能被很多service用到，我偏向于放在DAO层次。一旦涉及到DAO被多个service所用，那么你构造参数的过程将在各个不同的service里面重复，如果你要改变的话，bang！，全部都需要变化，这是典型的重复代码的例子。

我倒觉得放在Service层比较合适，你放到DAO层次就意味着在DAO的CRUD操作重复代码了，除非你不打算进行是否Cache的自由切换（不是指用参数判断）。而构造参数的重复代码可以用Helper类实现。

CRUD操作重复代码，怎么重复，我不理解？

用Helper，你的意思是

parameters=Helper.createCategoryKeyPageKeyParameters(categoryKey,pageKey)
dao.find(XXX,parameters)

而不是dao.getPage(CategoryKey,PageKey)?

放在service层，那你必须对每一个service都做缓存，并且很难用aop来拦截，简直就是不知道怎么拦截才能得到categoryKey和pageKey,除非你的每一个service都有一个

getPage(CategoryKey,PageKey)

方法

Cache切换是什么意思？这和在Service还是在DAO里面有什么区别？

我是这样考虑的

我的每个Service一般都会有Cache
例如
Interface UserManger
-- DefaultUserManger
-- CacheUserManger

DAO只管实际的操作，是否进行Cache不由DAO决定，而是由Service决定，一定要AOP吗？

你在DAO层面进行的Cache，是可以配置的Cache吗？

page2 page3？
这些是属于page的咚咚把。dao可以封装这么一个查询dao.getPageByName(id) (..)

某些时候在Service里面做cache是很有道理的，但在DAO层做Cache的情况更多一些，因为Cache往往是为了不从数据库中去取数据，也就是节约数据存取的时间。所以在很多情况下,cache是一个数据存取层的问题。

例如上面的情况，如果AService和BService需要使用这个PageDao.getPage()的话，那么我们没有理由让AService做Cache，然后让BService不做Cache

配置的问题到确实是无关的，放在哪里都可以自由配置，是一个注入的问题。

不用AOP也可以，不过我有一个小小的框架，只要进行适当的配置就可以实现Cache了，呵呵