谈了些实现问题，来说说几个题外话：
（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 部分配置信息供各位参考：
< configuration >
< dafConfiguration >
< dal >
< class name ="CustomerDal_ORM">
< method name ="GetAllCustomers"
DistributionType ="REMOTING"
cacheitem ="allcustomers" /> < cache >
< group name ="business">
< item name ="allcustomers">
< webapp absoluteExpiration ="12.0,hour"
priority ="High" />