关于web开发中页面依赖缓存的应用.txt

现状：

我们一般都是在业务中来缓存数据，比如投票数据。

我们一般在数据层使用缓存，比如 城市信息表。

我们一般在视图层使用缓存，比如页面输出缓存

问题：

业务中使用缓存，使用难度大，控制复杂

数据层使用缓存，使用简单，但能使用范围小，使用不当很容易造成数据滞后

视图层使用缓存，设置时间量缓存，使用简单，但能使用范围小，使用不当也很容易造成数据滞后

分析：

我们需要一个什么样的缓存系统呢？

我是这样想的，应该能有一个半自动的缓存系统，不用我自己写逻辑去控制缓存什么时候使用，什么时候更新，什么时候释放。

用户是通过页面和数据交互的，如果我将缓存放到视图层之前，那么所有用户的所有请求在交给视图层之前先由缓存系统处理，这样就不容易出现因缓存造成的数据滞后问题了。因为我的缓存控制层已经控制了所有用户的所有请求，这样缓存系统就可以根据用户请求的页面来更新其他与此页面关联的页面的缓存。

比如

A页面是添加信息页面，B页面是信息列表页面

我可在缓存系统中设置：B页面缓存会因为A页面被访问而更新，

也就是说 某个页面中的信息是与其他一个或者几个页面相关联的，如果相关联的某个页面被访问了，那么就应该更新应用此页面数据的其他页面的缓存更新，

其实在我们想在的开发中已经出现了这种预设了“数据关系”方式的缓存应用，有的应用在数据层，有的应用在业务逻辑层，我今天说的这种应用是在视图层。

一下是我对使用“数据关系”方式缓存在哪一层的利弊考虑

在数据层:数据关系易配置，但缓存数据量大，平均每个业务对应的缓存更改操作多，性能不好，并且缓存没有用到刀刃上

在业务层：不能大范围使用。由于业务层的数据关系复杂，数据关系不能或者不能正确配置

在视图层：由于缓存的就是用户要看的数据，故而缓存用到了刀刃上。页面关系配置难度不大，可大范围使用（整站使用）

当下，我也正在使用空闲时间开发这套缓存系统（.Net）。希望在我这套框架没有开发出来就已经有同类出色产品了。