讨论一下 cache 应该放在 service 层还是 dao 层吧

我个人倾向于放在 service 层。

因为虽然 hibernate 和 iBatis 都提供了 cache 机制，但是他们提供的方式都不是很完善。而且还有可能会使用其它 dao 的技术方案。所以放在 service 层应该更好一些。

注： cache 话题很大，我们只讨论 business layer 的 cache 问题，即 service 和 DAO。

要看你的Cache是干吗用的了

如果是对象Cache，自然是ORM透明化出来；
如果是查询Cache，自然是DAO层处理；
如果是Action Cache，自然是Web 层Action处理；
如果是Page Cache，自然是Servlet Filter处理；

缓存是个大概念，要看具体缓存的数据是什么特性的。

对象Id映射缓存ORM处理的不错。

查询缓存ORM比较傻瓜，一次增删变更，会使全部同类的查询缓存就被抹杀了。所以查询缓存可用DAO里面做。

页面缓存不是特经常使用，因为如果是整个页面需要缓存的话，可以利用http协议的一些头参数，在发送请求时设置一下搞定。

一般系统，在ORM中配置对象ID映射缓存和DAO的缓存做好了，代价较小，同时效果也很不错。

首先，你所说的cache应该指的就是对象的缓存，确切地说应该是持久化对象的缓存。那么这个“service 层的object cache”肯定得由你们自己来写了，我想这很难保证你们的cache使用效果会比底层下面“不是很完善的”hibernate 和 iBatis 提供的cache更好看。

再者，你们怎么保证“service 层的object cache”可以完好地与各不相同的“其它 dao 的技术方案”匹配上呢？而且又用什么机制保证“service 层的object cache”和数据库是同步的呢？直接连DB来获得更新了的碎片？或者专门写一些DAO层的接口，通过各自的实现来搞？

对于这个想法，我的第一感觉就是：not nice enough but naive enough

个人认为cache拿到前端控制比较好
每一层都放容易混乱
在表现层和service层，比较好控制，容易管理
前端控制，前面的口袋扎好就行了

Cache 这个东西，看似简单，但是具体实施起来却是很麻烦，有许多方面的因素需要考虑，很多实施不好的 cache 会成为系统故障和维护噩梦的重要源头。

所以我的原则是，只在一个层面上提供 cache 功能，其它的层面都不提供，以避免其复杂性并且降低耦合性。

就像各位所讲到的那样，cache 包括很多层面，而且会有一些特殊情况，这些应改需要根据具体情况具体分析了。这里我主要想讨论一下我们大多数情况下用到的的 cache 方案。页面 cache 也很重要，不过不再这里讨论了。

Allen 说：

这个说的非常对，实现自己的缓存方案比较麻烦一点，但并不是非常困难的事情，而且一个方案定下来之后可以不断地重用。

Allen 说：

我的想法是 DAO 只做 DAO 的工作，对开发应用的程序员提供的接口只有 service，不允许直接操作 DAO。这样应该就可以实现了。

:(
级别不够。。。。看不懂。。。。

LZ应该是指数据层的CACHE
最简单的一个HashMap Cache<Id, Object>, 或者<Sql, Object>
我不觉得数据访问层的CACHE放在SERVICE层会有额外的benefit
除非你要CACHE的是DOAMIN OBJECT

SERVICE需要的是DAO的服务 并不care你是从DB还是Cache去取得数据
可以通过比如AOP或者一个Decorate去配置Cache以对上层调用保持透明

对，我说的就是数据层的 cache，使用 aop 也需要考虑应该放在哪一层。Decorate 的方案就不在考虑范围内了，因为 pojo/dao/service，包括接口是实现类已经太多的类了。不想再添加新的类进去了。

在 service 层中实现的 cache 对上层应用也是透明的。

你认为AOP是layer-related吗?
Decorate模式并不会加重你开发或维护的负担 担心代码量只是一种pretense
getBusinessObject(){getCachedObject();} 这是一种透明吗