2007-02-08

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

关键字: cache
Cache 这个东西，看似简单，但是具体实施起来却是很麻烦，有许多方面的因素需要考虑，很多实施不好的 cache 会成为系统故障和维护噩梦的重要源头。 所以我的原则是，只在一个层面上提供 cache 功能，其它的层面都不提供，以避免其复杂性并且降低耦合性。 就像各位所讲到的那样，cache 包括很多层面，而且会有一些特殊情况，这些应改需要根据具体情况具体分析了。[color=blue]这里我主要想讨论一下我们大多数情况下用到的的 cache 方案。[/color][color=orange]页面 cache 也很重要，不过不再这里讨论了。[/color] Allen 说： [quote] 首先，你所说的cache应该指的就是对象的缓存，确切地说应该是持久化对象的缓存。那么这个“service 层的object cache”肯定得由你们自己来写了，我想这很难保证你们的cache使用效果会比底层下面“不是很完善的”hibernate 和 iBatis 提供的cache更好看。 [/quote] 这个说的非常对，实现自己的缓存方案比较麻烦一点，但并不是非常困难的事情，而且一个方案定下来之后可以不断地重用。 Allen 说： [quote] 再者，你们怎么保证“service 层的object cache”可以完好地与各不相同的“其它 dao 的技术方案”匹配上呢？而且又用什么机制保证“service 层的object cache”和数据库是同步的呢？直接连DB来获得更新了的碎片？或者专门写一些DAO层的接口，通过各自的实现来搞？ [/quote] 我的想法是 DAO 只做 DAO 的工作，对开发应用的程序员提供的接口只有 service，不允许直接操作 DAO。这样应该就可以实现了。
评论
ltian 2007-08-09
缓存处理确实是一个难题，希望多看到您的见解。
在系统中，我把某些基础数据在系统初始化时一次性加载到缓存中，然后对这些基础数据发生变化时更新缓存。但是当有多台应用服务器都需要缓存相同数据库的时候，问题就来了，因为只有一台应用服务器上的应用负责对这些基础数据进行维护，其他服务器只是读取。因此，必须通过JMS来同步缓存。麻烦啊。。。。。，不是很常用的数据还是少缓存为妙，否则弄不好影响数据处理的结果。
发表评论

您还没有登录，请登录后发表评论

jiming
搜索本博客
最近加入圈子
存档
最新评论