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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

Инъекция зависимостей.

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

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

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

Ответ 3

Я использую контекст в потоке. Это сложно настроить, но он очищает все, что нужно поговорить с db.

Ответ 4

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