Global.asax, глобальные переменные и редактирование с помощью кода

Question

У меня два вопроса:

1) У меня есть несколько глобальных переменных для моего сайта, объявленных в моем файле global.asax . Это простые, маленькие пары ключ / значение, и их всего несколько. Является ли это хорошей практикой для небольших ценностей, к которым нужно обращаться почти на каждой странице моего сайта? Хранение их в базе данных и требование поиска в базе данных выглядит как мысль, что это приведет к потере ресурсов для значений, которые не изменяются быстро.

2) Если одно из значений изменяется один раз в неделю, возможно ли разрешить пользователю редактировать глобальную переменную с помощью формы или каким-либо другим способом?

Пример:

<script runat="server">

  Overloads Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)

      Application("default_scoring_id") = 3
      Application("week_current") = 3

  End Sub

</script>

В приведенном выше примере системе необходимо знать, в какой неделе (из 15) текущая дата находится внутри. Таким образом, раз в понедельник утром значение «week_current» должно меняться.

Я могу легко это сделать, но есть ли способ предоставить пользователю доступ к изменению этого значения без касания кода?

Answer 1

Типичная практика - помещать их в файл web.config, который можно редактировать. Эти значения <appSettings> будут доступны на каждой странице, однако файл можно редактировать.

Answer 2

1) Хорошей практикой обычно является сохранение таких значений в web.config. См. здесь и здесь для некоторых руководств.

2) a) Если вы сохраните это в файле web.config, оно будет легко обновляться без перекомпиляции, и веб-приложение должно немедленно принять изменения.

b) Действительно ли обновление чего-то вроде «номера недели» должно быть ручным процессом? Это звучит немного подвержено ошибкам, и я бы предложил автоматизировать это, если это вообще возможно, рассчитав его на основе текущей даты.

Answer 3

Я хотел бы рассмотреть возможность использования встроенного кэша (System.Web.Caching.Cache)

Таким образом, вы можете хранить их в любом месте (например, в базе данных), легко изменять их из приложения и получать быстрый и дешевый поиск.

Внутри класса, который наследуется от BasePage, используйте данный объект Cache (например, Cache.Add (..)), а из других мест используйте HttpContext.Current.Cache (например, HttpContext.Current.Cache.Remove (Key))

Answer 4

<%@ Application Language="C#" %>

<script runat="server">

    void Application_Start(object sender, EventArgs e) 
    {
    // Code that runs on application startup

    }

    void Application_End(object sender, EventArgs e) 
    {
    //  Code that runs on application shutdown

    }

    void Application_Error(object sender, EventArgs e) 
    { 
    // Code that runs when an unhandled error occurs

    }

    void Session_Start(object sender, EventArgs e) 
    {

    // Code that runs when a new session is started

    }

    void Session_End(object sender, EventArgs e) 
    {
    // Code that runs when a session ends. 
    // Note: The Session_End event is raised only when the sessionstate mode
    // is set to InProc in the Web.config file. If session mode is set to StateServer 
    // or SQLServer, the event is not raised.

    }
    protected void Application_BeginRequest(Object sender, EventArgs e)
    {
    Context.Items.Add("Request_Start_Time", DateTime.Now);
    }
    protected void Application_EndRequest(Object sender, EventArgs e)
    {
    TimeSpan tsDuration = DateTime.Now.Subtract((DateTime)Context.Items["Request_Start_Time"]);
    Context.Response.Write("<b>Request Processing Time: From Global.asax file " + tsDuration.ToString());
    Application["time"] = tsDuration.ToString();
    }

</script>

Answer 5

Web.config - это способ .NET или ASP.NET, он не всегда самый эффективный или наиболее подходящий.

Ваш файл Global.asax - это намного больше, чем некоторые события, вы можете поместить статические данные в любой класс, который подкласс System.Web.HttpApplication, и унаследовать их в файле Global.asax.

HttpSessionState и HttpApplicationState - это реликвии с классического времени ASP, и вы бы хорошо их избежали, потому что подача не имеет никакой реальной цели.

В зависимости от типа (System.Type) ваших объектов вы можете создавать собственные строго типизированные объекты, которые хранят информацию о вашем приложении и сеансе, для данных уровня приложения будет достаточно кучки статических полей.

Они должны быть статическими, поскольку каждый модуль HttpModule, а также экземпляр HttpApplication являются объектами из пула, поэтому во избежание этой путаницы убедитесь, что ваши постоянные данные хранятся в статических или нескольких статических словарях. Но следует помнить о проблемах параллелизма при модификации этих коллекций. Хорошей стратегией является блокировка объекта, только на время, когда вы его модифицируете, и убедитесь, что вы не вызываете никакой другой код во время модификации коллекции, простой способ подкачки может быть полезен здесь, это быстро и не - гарантия блокировки.

Answer 6

Другие ответы предлагают различные способы, которыми это может быть сделано, и должно быть сделано. Но даже тогда, если вы хотите разрешить пользователю редактировать глобальную переменную, вам придется взять блокировку или Mutex для общего объекта, изменить значение вашей глобальной переменной и снять блокировку или Mutex.

lock(globalsharedobject) //This is C# code.
{
    Application("default_scoring_id") = 3;
}