实战 .Net 数据访问层 - 18

 

谈了些实现问题，来说说几个题外话：

（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