【问题标题】：Storing Application Variables存储应用程序变量
【发布时间】：2014-07-13 03:22:45
【问题描述】：

似乎存在三种不同的存储变量的方法，可用于应用程序中的每个请求：

Global.asax.cs

public class MvcApplication : HttpApplication
{
    protected void Application_Start()
    {
        Application["SiteDatabase"] = new SiteDatabase();
    }
}

欧文：

public partial class Startup
{
    public void ConfigureAuthentication(IAppBuilder Application)
    {
        Application.CreatePerOwinContext<SiteDatabase>(new SiteDatabase());
    }
}

静态容器

public static class GlobalVariables
{
    private SiteDatabase _Database;
    public SiteDatabase Database
    {
        get { return _Database ?? new SiteDatabase(); }
    }
}

每种方法的相对优势是什么？

【问题讨论】：

您最近似乎在问一些基本的 ASP.NET 问题，这些问题之前已（部分）在此站点上得到解答。你能试着展示一些研究吗？你能不能买一些 ASP.NET 的书？
别忘了数据库和Cache - 现在是5！
他们排序已经得到回答，但不是很明确。它们看起来很基本，但问题是由于新功能不断推出（例如，新版本的身份/实体框架非常注重使用 OWIN），很难确定新功能如何影响旧的做事方式.当我在谷歌上搜索这些问题并找到 2004 年的答案时，很难说该相信什么。

标签： asp.net asp.net-mvc session

【解决方案1】：

按顺序：

Global.asax.cs

优点：适用于所有 ASP.NET 应用程序，静态可用，因此您不必自己在应用程序周围流动数据。
缺点：不是强类型。不会在分布式环境中自动工作。

欧文

优点：在 OWIN 中工作得很好，并且可以在应用程序中流动。有些人认为使用静态是糟糕的编程。
缺点：如果您不使用 OWIN（例如 Katana），则不起作用。不会在分布式环境中自动工作。

静态容器

优点：适用于所有 ASP.NET 应用程序，静态可用。强类型意味着没有丑陋的演员表
缺点：它是静态的 :) 不能在分布式环境中自动工作。

数据库

优点：在分布式系统中工作
缺点：可能非常慢；可能由于网络问题而失败；需要更多代码才能可靠地实现。数据也必须是可序列化的。

缓存

优点：类似于数据库，但速度更快。
缺点：类似于数据库（但要快得多），而且缓存通常并不适用于长期存在的对象，尽管 ASP.NET 缓存确实提供了这种行为（但在这一点上，为什么要使用缓存）。

【讨论】：

这正是我想要的——我真的很感激！