Linq к разделению SQL & Logical (DAL, BLL)
Мы собираемся быть восстановлением одного из наших сайтов в .NET. Я прочитал много статей и действительно как идея разделить наш проект на уровень доступа к данным (DAL), Слой бизнес-логики (BLL) и уровень представления (мы происходим из классического ASP, таким образом, это - крупный шаг для нас). Мне также действительно нравится Linq к SQL.
Так как Linq к SQL нацелен на быструю разработку, действительно возможно с Linq к SQL иметь DAL, BLL и уровень представления? С Linq к SQL DAL возвратил бы объекты или код linq, который мог быть возможно изменен в BLL? Отношения между DAL и BLL с Linq к SQL, кажется, нечеткая тема без согласия - и так как это - такой большой переход для нас, я определенно хочу иметь хорошую стратегию прежде, чем погрузиться во что-либо.
Введенные Наборы данных кажутся более оборудованными для этого, но если бы я могу получить что-то похожее с Linq, я пошел бы тем путем.
Я хотел бы избегать nHibernate и других сторонних библиотек.
4 ответа
Мы строим именно то, что вы описали, и для этого используем L2S. Согласились, что отношения между DAL и BLL немного размыты, но у нас есть отдельный BLL и отдельный DAL. Вся наша логика находится в BLL, и все извлечение/модификация данных осуществляется через вызовы DAL (используя вызовы LINQ).
Наше приложение не использует набранные наборы данных. Мы построили классы сущностей для представления наших объектов. Теперь, когда я потратил пару месяцев на сборку этой части, я не вижу, чтобы мы (я) когда-либо возвращались к наборам данных.
Также, я бы не зацикливался на L2S, который "нацелен на быстрое развитие". Это делает его похожим на инструмент прототипирования. Мы находим его индустриальным сильным инструментом. Это может противоречить тому, что сейчас может сказать об этом Microsoft, так как они предпочитают, чтобы люди использовали EF.
Рэнди
Я рекомендую сделать один шаг назад и еще раз взглянуть на свои требования.
Вам нужны настоящие 3 уровня (то есть физическое развертывание на разных машинах) или просто логическое разбиение вашего приложения?
Я сделал именно эту ошибку на первом большом приложении, которое я написал. Мне никогда не нужны были физические 3 уровня (и никогда не понадобятся), но я разработал приложение таким образом. Самым поразительным последствием было то, что я Linq2Sql не поддерживает отключенную функцию отслеживания изменений на сущностях. Я использовал Linq2Sql Entity Base для обхода этого ограничения, однако оно очень сильно нарушает концепцию Persistence Ignorance (после этого всегда лучше знать, да?)
Переход на реальные n-уровни имеет много других последствий для архитектуры приложения.
Вам понадобится передача сообщений, объектов передачи данных и т.п. Linq2SQL - достойный ORM, тесная интеграция с LINQ предоставляет уникальные возможности. Остальным ORM все равно понадобится некоторое время, чтобы наверстать упущенное. NHibernate 3.0 - свет в конце туннеля здесь. Linq2SQL - отличный ORM, если у вас есть простые модели данных, и вы можете создавать карты "по классу на таблицу".
Для отключенного отслеживания изменений (которое вам понадобится, если вы пойдете на n-уровень) другие ORM имеют лучшую поддержку.
И наконец:
(мы пришли от классического ASP так что это это огромный шаг для нас)
В этих условиях я был бы особенно осторожен. Технологии переключения часто недооцениваются. Даже самые умные программисты в вашей команде будут принимать неверные решения, потому что им не хватает опыта работы с технологией. Тем не менее, важно идти новыми путями и совершенствовать свои навыки. Те, кто никогда не потерпит неудачу, никогда не будут судиться.
.Я бы сказал, что L2S - это DAL. L2S + бизнес-логика в отдельных классах становится объединенной DAL+BLL, сторона DAL - это время выполнения L2S, а генерируемый L2S код (текст данных, классы сущностей и т.д.)
Вы все еще можете легко отделить их так, чтобы часть, генерируемая L2S, и любые расширения к сущностям и тексту данных были в отдельной DLL, а дополнительная бизнес-логика - в отдельной dll/service/etc. Однако во многих случаях реальной необходимости в их разделении нет.
Одна из причин разделения на DAL+BLL при использовании L2S будет заключаться в том, что вы предполагаете переход на другую технологию доступа к данным вниз по дороге, или если вы используете более одной технологии доступа к данным. Наличие отдельной DAL с любой специфической для L2S технологией должно облегчить переключение DAL. Если по этой причине вы хотите отделить DAL+BLL, то L2S DAL-DLL должна раскрывать классы сущностей, любые производные классы или классы проекции, а также методы получения сущностей или коллекций (List и т.д.), но держать DataContext внутри класса DAL во избежание просачивания в BLL специфических для L2S вещей (L2S запросов и т.д.)
JMHO.
Так как другие упоминали инструменты L2S, вот более полное описание того, что там есть: http://www.thinqlinq.com/post.aspx/title/linq-tools
IMHO, LINQ к SQL - лучший выбор, доступный в настоящее время. Он действительно делает работу с данными безболезненной и почти увлекательной. :-) Если вас интересует LINQ to SQL, то я бы посмотрел на наш проект PLINQO. В нем есть несколько замечательных улучшений LINQ до SQL, чтобы сделать его лучшим общим решением.
.