<!--[endif]-->
缓存处理应该是老生长谈了，缓存处理的好坏直接关系到一个项目的质量。我一个小菜鸟，虽然对缓存知道些，真正的应用也是近期才开始，看到的、接触到的大部分都是对缓存存取的封装，每每看到更方便的缓存处理的例子，都大呼过瘾，缓存处理都这样地步了，真是方便，呵呵。。。。。。。
今天看了.net petshop的缓存处理。原来也看过petshop，都没认真看，以为也无非是处理的一些封装，今天一看才只知道自己真是一厢情愿。petshop中写了三个缓存相关的项目，接口层：ICacheDependency，具体实现层：TableCacheDependency，对外提供的统一访问的：CacheDependencyFactory。这些项目可以说与原来所以为的缓存存取的封装没有一点关系，最终的目的是获取设置缓存依赖。整个petshop项目好像也没有对缓存存取进行封装，都是在使用时进行的判断（不知道说的对不对，不对的话，大家拿砖拍醒我）。
至于这样吗，对个缓存依赖这么大动干戈，真是。。。。。又想了一想，有点感觉自己原来的想法可能错了，原来注重对缓存存取的封装，无非这样自己程序时方便；而petshop考虑的就不一样，更注重的缓存的有效性，更注重数据的一致性。。。。。。。。。自己竟然为了程序时的方便，忽略最重要的东西：数据，数据的有效性。
今天缓存没白看，至少纠正了自己一直以来的错误思想。不过对缓存依赖，虽然一开始就知道，但是真的是忽略了，也只是想着短暂的数据失效应该没什么关系的。。。。。。。呵呵。。。。
可能自己对缓存依赖的排斥，有个想法：设什么缓存依赖呢，自己程序实现不得了。例如product物品信息，能导致数据库变动的无非就是我们页面上的修改、添加、删除，而这些又是我们封装的最好的地方，我们何不在这些操作上根据自己的需要手动处理缓存呢，这样就不用设置缓存依赖，不用让系统去监视更改。这样我们还可以获得更大的自由，我们甚至可以在操作的时候直接把缓存换成最新的，这样就可以保证浏览的时候总是从缓存中获取的。不过这样好像有点浪费，即使是这样，我们获取数据也要检测缓存，以应付可能其它原因造成的缓存丢失。不过理想状态下应该不错，既保证了缓存有效性，又节省第一次浏览的时间，只是浪费些修改时的时间，不知道值不值。。。。。。。。。。
哎，想自己太注重缓存存取方便的，赶快纠正过来：考虑好了保证缓存的效性，之后再去处理封装缓存的操作吧。。。。。。。。。。。
<!--[endif]-->