如何在ASP.NET 2.0分层架构中实现数据缓存以优化长尾查询效率？

本文共计4159个文字，预计阅读时间需要17分钟。

导语：正面临章节所述，缓存ObjectDataSource的数据只需进行一些简单属性设置。然而，它是在表现层对数据进行缓存，这与ASP.NET页面缓存策略（缓存+策略）紧密耦合（紧密耦合）。

导言：

　　正如前面章节所言，缓存ObjectDataSource的数据只需要简单的设置一些属性。然而，它是在表现层对数据缓存，这就与ASP.NET page页面缓存策略(caching policies)紧密的耦合(tightly couples)起来。我们对体系机构分层的原因之一便是打破这种耦合。拿业务逻辑层为例，将业务逻辑从ASP.NET页面脱离出来；而数据访问层将数据访问的细节ASP.NET页面脱离出来。从某种意义来说，将业务逻辑和数据访问细节脱离出来是首先，这样的话使系统更易读、易维护、易修改，便于按模块分工—比如，表现层的开发者对数据库的细节不甚了解也不妨碍其开发工作。当然，将缓存策略从表现层脱离出来也有类似的好处。

　　本文我们将对层次机构进行扩充，新添一个缓存层(Caching Layer,简称CL)以实施缓存策略。该缓存层包括一个ProductsCL类，该类用类似 GetProducts(), GetProductsByCategoryID(categoryID)等方法来访问产品信息。调用这些方法时先从内存检索数据，如果内存为空则调用业务逻辑层BLL里的ProductsBLL类的相应方法，再从数据访问层DAL返回获取的数据。该ProductsCL类的方法从业务逻辑层BLL获取数据后先对数据缓存后再返回。

如图1所示，缓存层CL位于表现层和业务逻辑层。

图1：在我们的体系结构中缓存层(CL)是单独的一层

第一步：创建缓存层的类

　　在本文，我们创建的缓存层仅仅包含一个ProductsCL类，它只有几个方法。
　　完整的缓存层还应该包含CategoriesCL, EmployeesCL, 和SuppliersCL类。