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

Question

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

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

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

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

Answer 1

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

http://dotnetlog.com/archive/2008/03/18/best-practice-and-efficient-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 2

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

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

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

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

Answer 3

Вам следует быть осторожным с терминологией.Когда вы говорите LINQ, вы имеете в виду Linq-to-sql, а когда вы говорите «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-hopeful-a-realistic-world.aspx)