Лучшие практики: 3-уровневая архитектура в LINQ

Question

Я работаю над личным проектом (C # / ASP.NET), который будет использовать LINQ to SQL. Решение будет иметь (пока) проект Webform, проект пространства имен (бизнес-логика) и проект Tests. Пока я нахожусь на очень ранних стадиях (явно на этапе проектирования).

Есть ли здесь парадигма для 3-уровневой архитектуры? Кажется, что DAL в этом случае совершенно бесполезен; Мне кажется, что я должен выполнять запрос LINQ непосредственно из бизнес-логики.

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

Я нашел эту ветку , но кажется, что она рисует неполную картину. Есть ли какие-нибудь подробные статьи на эту тему?

Answer 1

Вы можете прочитать немного о домене, управляемом дизайном.

С практикой доменного управления (DDD) у вас есть богатая «доменная модель», в которой вы выражаете проблемный домен, который вы хотите решить. Эта модель предметной области состоит из классов (и структур), с помощью которых вы моделируете свои бизнес-объекты. Модель предметной области также состоит из репозиториев.
Репозиторий - это некая абстракция, которую вы используете в своей модели предметной области (и в своем приложении); Репозиторий - это абстракция вашего хранилища данных. Через хранилище вы можете извлекать сущности и использовать хранилище для сохранения сущностей.

В вашем случае ваши репозитории могут использовать Linq To SQL для связи с базой данных. Однако обратите внимание, что ваш репозиторий не должен нести ответственность за управление (открытие / закрытие) соединением и транзакцией (запуск / принятие / откат). Зачем ? -> потому что репозиторий не знает и не понимает контекст, в котором он используется. Именно ваше приложение или сервисный уровень (уровень, который использует модель вашего домена и, следовательно, ваш репозиторий), должен отвечать за открытие нового соединения и запуск / принятие транзакций. (Или в вашем случае откройте новый DataContext). Затем вы можете передать DataContext в хранилище.

(у Эрика Эванса есть отличная книга о DDD, хотя время от времени он крепкий орешек).

Answer 2

Вы можете думать о LINQ-to-SQL как о своем DAL, поэтому использование его «непосредственно из бизнес-логики» не обязательно является плохой вещью.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx содержит некоторые популярные подходы L2S.

В нашем проекте мы не хотели передавать контекст данных, поэтому мы использовали шаблон, аналогичный # 3 из приведенной выше ссылки (Ambient DataContext, см. Ниже). У него были некоторые проблемы, но он работал достаточно хорошо; по крайней мере, для нашего веб-проекта.

Ambient DataContext (используется в настоящее время)

Идея скрытого текстового контекста заключается в том, что контекст создается для определенного потока или httpcontext (в asp.net), как только происходит первый вызов DataContext. Затем тот же контекст используется для этого потока или запроса, если он не расположен вручную. Это делается путем сохранения контекста в хранилище данных запроса / потока. Подход к этому шаблону аналогичен статическому DataContext, однако для каждого потока и запросов предусмотрено разделение. Это работает очень хорошо в Asp.Net, однако, снова страдает от некоторых проблем статического контекста.

Проблемы с этим шаблоном:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 3

Вы должны быть осторожны с вашей терминологией. Когда вы говорите LINQ, вы имеете в виду Linq-to-sql, а когда вы говорите 3-уровневый, это обычно означает, что вы говорите о сценарии развертывания с 3 отдельными компьютерами. Я не уверен, что ты имеешь в виду.

Трехслойная архитектура все еще является хорошей идеей при использовании инструмента ORM, такого как linq-to-sql. DAL становится просто местом для хранения вашей логики запросов. Хорошей идеей будет исключить ваши запросы из бизнес-уровня, потому что запросы - это постоянная проблема, а не бизнес-логика.

Обычная техника для управления контекстом данных - иметь один контекст данных на запрос.

С точки зрения других статей по этой теме вы можете посмотреть любое руководство по архитектуре для любого инструмента ORM - linq-to-sql ничем не отличается. Ищите статьи об архитектуре для NHibernate.

Answer 4

В данном случае библиотека LINQ to SQL - это ваш DAL, и вместо традиционных вызовов API из вашего бизнес-уровня (например, DAL.GetObjectById (id)) у вас есть гибкость для гораздо более выразительных запросов в DAL.

Если бы у вас были какие-то другие потребности, например, ваш собственный поставщик LINQ, который подключается к поддержке данных, не относящейся к MSSQL, то вы бы реализовали свой собственный DAL.

Кроме того, что касается DataContext, не рекомендуется использовать одноэлементный шаблон с «одним резидентным DataContext». Объект DataContext должен представлять одну логическую транзакцию, что бы это ни значило для вашего приложения. (Перефразировано с http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx)