LinqToSql статический DataContext в веб-приложении
5 ответов
Это не статическая копия. Обратите внимание, что свойство извлекает его из Context.Items для каждого запроса. Это копия DataContext для каждого запроса, доступ к которой осуществляется через статическое свойство.
С другой стороны, это свойство предполагает наличие только одного потока на запрос, что не может быть истинным навсегда.
DataContext дешев в изготовлении, и вы не выиграете от его кэширования таким способом.
Я сделал много веб-приложений Linq to Sql, и я не уверен, что то, что у вас есть, будет работать.
Текст данных должен отслеживать изменения, которые вы вносите в свои объекты, и он будет не делайте этого в данном случае.
Поэтому, когда вы нажмете кнопку «Отправить изменения», он не будет знать, что какие-либо из ваших объектов были обновлены, и, следовательно, не обновит базу данных.
Вы должны проделать некоторую дополнительную работу с текстом данных в отключенная среда, такая как веб-приложение. С обновлением сложнее всего, но не так уж и плохо. Я бы не кэшировал, а просто создавал заново.
Я предпочитаю создать базовый класс Page (унаследовать от System.Web.UI.Page) и предоставить свойство DataContext. Это гарантирует, что существует один экземпляр DataContext на запрос страницы.
Это сработало для меня, это хороший баланс ИМХО. Вы можете просто вызвать DataContext.SubmitChanges () в конце страницы и быть уверенным, что все обновляется. Вы также гарантируете, что все изменения предназначены для одного пользователя за раз.
Выполнение этого через static вызовет боль - я боюсь, что DataContext потеряет отслеживание изменений, поскольку он пытается отслеживать изменения для многих пользователей одновременно. Не думаю, что он был предназначен для этого.
Выполнение этого через static вызовет боль - я боюсь, что DataContext потеряет отслеживание изменений, поскольку пытается отслеживать изменения для многих пользователей одновременно. Не думаю, что он был предназначен для этого.
Выполнение этого через static вызовет боль - я боюсь, что DataContext потеряет отслеживание изменений, поскольку пытается отслеживать изменения для многих пользователей одновременно. Не думаю, что он был предназначен для этого.
Кроме того, сам контекст не является транзакционным, поэтому теоретически возможно обновление по другому запросу, и ваше обновление может завершиться ошибкой.