谈了些实现问题,来说说几个题外话:
(1) 性能问题:cache management能显著提高数据访问效率,但对内存的要求比较高,尤其是在web application或remoting server这种应用环境下!
所以,这就要求我们应该将“钱”用在“刀刃”上(对内存毫不在乎者除外j),不能乱花钱!
一般,对于系统数据(如:应用 / 模块,组 / 用户 / 权限等)或lookup data(如:婚姻状况列举 / 政治面貌列举等),可以考虑放入cache;另外,如果客户(请注意:不是开发人员!)认为变动可能性较小或频率不高的business data也可以考虑放入cache;
(2) 手工刷新:cache是把双刃剑,带来便利的同时也增添烦恼。“手工刷新数据”可能就是其中最麻烦的事情!
在系统调试阶段,我们还可以通过关闭cache功能(在配
置信息中注释掉相关内容)来避免这个问题,可一旦上线,
就只能通过其它方式进行解决了!
在这里,作者先试着给出3种解决方案:
i. 对于web application,可以利用.net framework提供的dependency机制将cache绑定至文件系统,一旦数据变化,只需更新相关文件或目录信息即可达到cache refresh目的(不符合ease of use标准l)!但对于windows application,dependency就需要自己实现了l
ii. 可以使用observer pattern将所有的data access logic更新操作进行登记,一旦调用更新方法,立刻执行相关delegate以更新cache data!
这或许是一个对客户最为友好的解决方案(有个限制
条件:客户不能直接修改database数据j),但对开
发人员却是一个无尽的“折磨”(整天提心吊胆,总
担心忘了登记l)!
iii. 自己实现一个ui,对cache data进行refresh management!这是个介于上面两种方法间的折衷方案,也是作者比较倾向的一种思路(当然了,如果哪位朋友有兴趣将上面3种统统实现并有机整合之,那就功德无量了j)。
最后,奉上作者机器上的cache部分配置信息供各位参考:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<dafconfiguration>
<dal>
<class name="customerdal_orm">
<method name="getallcustomers"
distributiontype="remoting"
cacheitem="allcustomers" />
</class>
</dal>
<cache>
<group name="business">
<item name="allcustomers">
<webapp absoluteexpiration="12.0,hour"
priority="high" />
<winapp accesscount="2" />
</item>
</group>
</cache>
</dafconfiguration>
</configuration>
下一段:http://www.csdn.net/develop/read_article.asp?id=27562