В веб-приложении, с которым я столкнулся, я нашел следующий код для работы с DataContext при работе с LinqToSQL

public partial class DbDataContext
  {
    public static DbDataContext DB
    {
      get
      {
        if (HttpContext.Current.Items["DB"] == null)
          HttpContext.Current.Items["DB"] = new DbDataContext();
        return (DbDataContext)HttpContext.Current.Items["DB"];
      }
    }
  }

Затем ссылаемся на это позже, выполняя это:

DbDataContext.DB.Accounts.Single(a => a.accountId == accountId).guid = newGuid;
DbDataContext.DB.SubmitChanges();

Я изучал лучшие практики при работе с LinqToSQL.

Я не уверен в подходе, который использовался при работе с DataContext, который не является ThreadSafe и хранит его статическую копию.

Это хороший подход к веб-приложению?

@ Longhorn213 - Исходя из того, что вы сказали, и чем больше я прочитал в HttpContext из-за этого, я думаю, что вы правы. Но в приложении, которое я унаследовал, это сбивает с толку, потому что в начале каждого метода они запрашивают БД для получения информации, затем модифицируют этот экземпляр datacontext и отправляют в него изменения.

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

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