Несколько / один экземпляр Linq to SQL DataContext

Question

У меня есть проект с множеством различных классов, запрашивающих и изменяющих данные в общем наборе таблиц. Я настроил файл .dbml, который предоставляет нам класс DataContext. Мой вопрос заключается в том, должен ли один экземпляр DataContext использоваться всеми объектами или безопасно ли использовать несколько экземпляров. Мне также интересно узнать о безопасности потоков в случае одного DataContext и о том, следует ли синхронизировать доступ к его методам.

Answer 1

Rick Strahl имеет хорошую статью о ваших возможностях: http://www.west -wind.com / weblog / posts / 246222.aspx .

См. Также: LINQ to SQL - где находится ваш DataContext? .

Возможно, вам понадобится немного другая стратегия для каждого типа развертывания - веб, рабочий стол, служба Windows ...

Подведем итог, ваши варианты:

• Global DataContext - опасен в многопоточных средах (включая веб-приложения). Помните, что члены экземпляра не гарантируют поточно-ориентированность (из ответа Брэдли Грейнджера выше).
• DataContext для потока - сложно. Если ваш DataContext отслеживает изменения, вы должны обязательно сбросить их в соответствующее время. Создание, хранение и извлечение DataContext - это боль.
• DataContext на элементарное действие - вы теряете возможность отслеживать изменения, поскольку один DataContext создает объект, а другой обновляет или удаляет его. Присоединение объекта данных к новому DataContext может работать не так, как вы ожидаете.
• DataContext для каждого объекта данных - кажется не элегантным, потому что вам приходится возиться с DataContext при создании экземпляра (создавать и присоединять) и обновлять / удалять (извлекать его из объекта данных и использовать его).

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

Answer 2

Я использую новый экземпляр DataContext для каждой транзакции.

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

Если вам нужен элемент длиннее, чем для транзакции, вы можете отсоединить его от DataContext, клонировав элемент, и позже можете присоединить его к новому и свежему DataContext с помощью Attach ().
Я даже могу клонировать элемент, отправить его по сети с помощью WCF, вернуть его при более позднем вызове, присоединить его к новому DataContext и сохранить изменения (конечно, для этого мне нужен столбец метки времени).

Answer 3

Класс DataContext достаточно легкий, чтобы его можно было создавать снова и снова. Это упрощает доступ к объектам сущности в пределах одного метода. Если вам нужно получить доступ к одним и тем же объектам LINQ из разных классов и методов, оставив их подключенными к DataContext для целей отслеживания, также можно сохранить один экземпляр.

Answer 4

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

Именно поэтому я использую объект контекста данных для каждого из моих классов - мой класс User имеет свой собственный контекст данных, мой класс Application имеет свой собственный и т. Д.

Этот шаблон устраняет большинство проблем, связанных с выполнением отката в моих проектах.

Answer 5

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

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