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