LinqToSql статический DataContext в веб-приложении - PullRequest
Новая
       8

LinqToSql статический DataContext в веб-приложении

8 голосов
/ 02 июня 2009

В веб-приложении, с которым я столкнулся, я нашел следующий код для работы с 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 и отправляют в него изменения.

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

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

Ответы [ 5 ]

6 голосов
/ 02 июня 2009

Это не статическая копия. Обратите внимание, что свойство извлекает его из Context.Items, который является для каждого запроса. Это копия DataContext для каждого запроса, доступ к которой осуществляется через статическое свойство.

С другой стороны, это свойство предполагает только один поток на запрос, что не может быть правдой вечно.

0 голосов
/ 03 июня 2009

Я предпочитаю создавать базовый класс страницы (наследовать от System.Web.UI.Page) и предоставлять свойство DataContext. Это обеспечивает наличие одного экземпляра DataContext на запрос страницы.

Это хорошо сработало для меня, это хороший баланс ИМХО. Вы можете просто вызвать DataContext.SubmitChanges () в конце страницы и быть уверенным, что все обновлено. Вы также гарантируете, что все изменения предназначены для одного пользователя одновременно.

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

0 голосов
/ 02 июня 2009

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

0 голосов
/ 02 июня 2009

Я сделал много веб-приложений Linq to Sql, и я не уверен, сработает ли то, что у вас есть.

Предполагается, что datacontext будет отслеживать изменения, которые вы вносите в свои объекты, и в этом случае этого делать не будет.

Таким образом, когда вы нажмете «отправить изменения», он не будет знать, что какой-либо из ваших объектов был обновлен, поэтому не будет обновлять базу данных.

Вы должны проделать дополнительную работу с текстом данных в автономной среде, такой как веб-приложение. Сложнее всего с обновлением, но не так уж и плохо. Я бы не кешировал и просто воссоздал его.

0 голосов
/ 02 июня 2009

A DataContext дешево сделать, и вы не получите много, кэшируя его таким образом.

...