为什么使用 System.Runtime.Caching 或 System.Web.Caching VS 静态变量

本文关键字：System Caching VS 静态 变量 Web Runtime 为什么 | 更新日期: 2023-09-27 17:56:23

长时间侦听器 - 第一次调用者。 我希望得到一些建议。 我一直在阅读有关.net缓存的信息 - 包括System.Web.Caching和System.Runtime.Caching。 我想知道与简单地创建带有锁定的静态变量相比，我可以获得什么额外的好处。 我目前的（头脑简单）缓存方法是这样的：

public class Cache
{
    private static List<Category> _allCategories;
    private static readonly object _lockObject = new object();
    public static List<Category> AllCategories
    {
        get
        {
            lock (_lockObject)
            {
                if (_allCategories == null)
                {
                    _allCategories = //DB CALL TO POPULATE
                }
            }
            return _allCategories;
        }
    }
}

除了过期（我不希望它过期）之外，我不知道使用内置缓存有什么好处。

也许更复杂的缓存方案有一些好处，但不适用于我 - 或者我只是错过了一些东西（不会是第一次）。

那么，如果我想要一个永不过期的缓存，使用缓存有什么好处呢？静态变量不这样做吗？

为什么使用 System.Runtime.Caching 或 System.Web.Caching VS 静态变量

首先，Xaqron提出了一个很好的观点，即您所说的可能不符合缓存的条件。它实际上只是一个延迟加载的全局可访问变量。 这很好：作为一个实用的程序员，没有必要向后弯腰来实现完全的缓存，因为它并不真正有益。但是，如果要使用此方法，不妨Lazy让 .NET 4 完成繁重的工作：

private static Lazy<IEnumerable<Category>> _allCategories
    = new Lazy<IEnumerable<Category>>(() => /* Db call to populate */);
public static IEnumerable<Category> AllCategories 
{ 
    get { return _allCategories.Value; } 
}

我冒昧地将类型更改为IEnumerable<Category>，以防止呼叫者认为他们可以添加到此列表中。

也就是说，任何时候你访问一个公共静态成员，你都会错过面向对象编程必须提供的很多灵活性。我个人建议你：

  1. 将类重命名为 CategoryRepository（或类似的东西），
  2. 使此类实现一个ICategoryRepository接口，并在接口上使用GetAllCategories()方法，并且
  3. 将此接口注入到任何需要它的类中。

这种方法将使您能够对应该对所有类别执行操作的测试类进行单元测试，完全控制测试哪些"类别"，而无需数据库调用。

System.Runtime.Caching和System.Web.Caching具有自动过期控制，可以基于文件更改，SQL Server DB更改，并且您可以实现自己的"更改提供程序"。您甚至可以在缓存条目之间创建依赖关系。

请参阅此链接以了解有关 System.Caching 命名空间的更多信息：

http://msdn.microsoft.com/en-us/library/system.runtime.caching.aspx

我提到的所有功能都记录在链接中。

使用

静态变量需要手动控制过期时间，并且必须使用文件系统观察程序和缓存命名空间中提供的其他观察程序。

Other than expiration (and I wouldn't want this to expire) ...

如果你不关心寿命，这个名字就不再caching了。

仍然使用Application（您的案例）和Session对象是存储应用程序级别和会话级别数据的最佳做法。

相关文章：