Linq to SQL: правильно ли использовать только один DataContext на запрос?

Question

Мы используем Linq to SQL здесь. В настоящее время наши репозитории имеют тенденцию обновлять свои собственные объекты DataContext, поэтому, если вы работаете с несколькими репозиториями, вы работаете с несколькими DataContexts.

Я делаю некоторый рефакторинг, чтобы разрешить внедрение зависимостей в нашу работу. Я предположил, что нам нужен шаблон «1 DataContext на запрос», поэтому я внедряю один и тот же DataContext (уникальный для веб-запроса) во все репозитории.

Но потом что-то случилось сегодня. После моего рефакторинга мы получили исключение ForeignKeyReferenceAlreadyHasValueException, поскольку вместо соответствующего свойства ассоциации было установлено поле внешнего ключа. Насколько я могу судить по Google, прямая установка внешнего ключа в Linq для SQL неверна (т. Е. Наш код был ошибочным), но мы не получили ошибку, пока я не произвел рефакторинг.

Так что я просто хотел проверить - действительно ли один DataContext на запрос - правильный путь?

Answer 1

Один DataContext на запрос - это единственный способ, не единственный, но обычно хороший.

Используя один DataContext, вы можете сохранить все отправленные данные до конца запроса и сразу отправить все изменения. SubmitChanges автоматически инкапсулирует все изменения в транзакции.

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

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

Answer 2

Если вы используете транзакции, то вы обнаружите, что метод множественных данных создает новое соединение с БД для каждого нового репозитория, в котором новый текст данных обновляется, пока транзакция в транзакции находится в ожидании.Мы столкнулись с этим, когда область транзакции завершила запрос, который выполнял работу с большим количеством объектов репозитория и исчерпал количество соединений в пуле.Поэтому, если вы планируете использовать trnasactionscope для управления сложными бизнес-процессами в транзакции, обязательно используйте общий текстовый текст.