LINQ to SQL - где живет ваш DataContext?

Question

Я использую LINQ to SQL в библиотеке объектов доступа к данным. Библиотека используется как в веб-контексте (веб-приложение / веб-служба), так и в не-сети (служба Windows). Первоначально я сохранил DataContext на текущем HttpContext, поскольку он позволял мне управлять довольно маленькой единицей работы (один веб-запрос) и избегал глобальных объектов в веб-приложении. Очевидно, это не работает в службе Windows.

У Рика Страля есть хорошая статья по управлению временем жизни DataContext: http://www.west -wind.com / weblog / posts / 246222.aspx . К сожалению, я не могу определиться с лучшим подходом. Глобальный DataContext не работает по причинам, о которых он упоминает, отдельный поток DataContext кажется сложным и потенциально более сложным, чем он стоит, а экземпляр для каждого объекта кажется суетливым - вы теряете некоторую элегантность, когда присоединяете DataContext используется для создания DAO для этого DAO, чтобы он мог update или delete позже - не говоря уже о том, что в отношениях есть что-то неприятное, смешное.

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

Answer 1

Рекомендации из документации MSDN для класса DataContext - вот что я бы порекомендовал:

В общем случае экземпляр DataContext рассчитан на одну единицу работа "однако ваше приложение определяет этот термин. DataContext - это легкий и не дорогой Создайте. Типичный LINQ to SQL приложение создает DataContext экземпляры в области видимости метода или как член недолговечных классов, которые представляют собой логический набор связанных операции с базой данных.

Поскольку DataContext - это IDisposable, я считаю, что проще всего создать и использовать DataContext в операторе using в одном методе, поэтому его можно правильно утилизировать.

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

Answer 2

Внедрение зависимостей.

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

Также DataContexts реализуют IDisposable, поэтому вам действительно нужно управлять их временем жизни. Все наши веб-формы имеют базовый класс, и часть этого является свойством datacontext (лениво создано). Таким образом, все на странице может делиться ею, что чаще всего имеет место. Контекст удаляется вручную в событии OnUnload () страницы.

---

• Вы не должны смешивать сущности linq из разных контекстов данных, и вы обычно сталкиваетесь с проблемами, если используете сущности linq, если datacontext был Dispose () 'd of.

Answer 3

Я использую контекст для каждого потока. Его сложно настроить, но он очищает все, что нужно для разговора с БД.

Answer 4

Я использую httpcontext в веб-сценариях и контекст потока для всего остального. Мы создали небольшую структуру, чтобы контекст данных был полностью абстрагирован от уровня представления / бизнеса.