При разработке бизнес-объектов я пробовал несколько различных методов написания уровня доступа к данным. Некоторые из них сработали лучше, чем другие, но я всегда чувствовал, что должен быть «лучший» способ.
Мне просто хотелось бы увидеть, как люди по-разному обращались с DAL в разных ситуациях, и их мнение о том, как эта техника работала или не работала хорошо.
Я в значительной степени полагался на статью / образец Билли Маккафферти о лучших практиках NHibernate. код для многих приложений Web / WinForms. Это прекрасно написанная статья, которая предоставит вам хороший надежный образец архитектуры - в дополнение к обучению основам NHibernate и TDD. Он пытается дать вам обзор своей архитектуры и дизайнерских решений.
Он создает очень элегантный DAL, используя общие объекты DataAccessObjects, которые вы можете расширить для каждого объекта домена, и очень слабо связанный с BL с помощью интерфейсов и DAOFactory. Я бы порекомендовал сначала взглянуть на BasicSample, особенно если вы раньше не работали с NHibernate.
Обратите внимание, эта статья в значительной степени опирается на NHibernate, но я думаю, что общий подход к ней можно легко изменить для соответствия другим ORM.
К сожалению, я не думаю, что есть «лучший способ», он слишком зависит от конкретной ситуации относительно того, какой подход DAL вы используете. Прекрасное обсуждение «современного состояния» - это Шаблоны Архитектура корпоративных приложений Мартина Фаулера.
В главе 10 «Архитектурные шаблоны источников данных» конкретно рассказывается о большинстве наиболее часто используемых шаблонов для бизнес-приложений.
В целом, я считаю, что наилучшим выбором является простейший подход, отвечающий основным требованиям ремонтопригодности и адаптируемости.
Например, в недавнем проекте мне был нужен простой «Шлюз строк данных». (Это были просто классы, сгенерированные кодом для каждой соответствующей таблицы базы данных, включая методы для выполнения операций CRUD). Никаких бесконечных споров о ORM и хранимых процессах, это просто работало и выполняло требуемую работу хорошо.
Есть несколько общих закономерностей. Книга «Шаблоны корпоративной архитектуры» является хорошая ссылка для них:
Если вы используете ORM, например llblgen, вы можете выбрать самообслуживание или адаптер.
Если вы идете по маршруту NHibernate (хорошая ссылка на статью, кстати, от @Watson выше), я настоятельно рекомендую вам проверить образец проекта suvius-flamingo от codebetter. У него есть очень хороший и лаконичный пример проекта, который демонстрирует MVC и NHibernate в действии.
Я предполагаю, что вы имеете в виду написание DAL, обращающегося к SQL, потому что сегодня это наиболее распространенная часть. ОДНАКО, если самая большая проблема при написании DAL для SQL - это часть ORM. То есть существует фундаментальное несоответствие импеданса между объектно-ориентированным программированием и схемами реляционных баз данных. Было много отличных и даже успешных попыток написания ORM. Но все они страдают от одной и той же проблемы, заключающейся в их преимуществе: они отвлекают вас от базового генерируемого SQL. Это проблема в том, что производительность вашей базы данных является критическим компонентом того, насколько хорошо ваша система функционирует в целом. Многие ORM (возможно, большинство) не только имеют невысокую производительность для многих стандартных запросов, но и фактически поощряют шаблоны использования, которые значительно ухудшают производительность (частый пример - многократное прохождение отношений внутри циклов при запросе коллекций, что затрудняет разрешение взаимоблокировок. Другая). Конечно, после детального изучения ORM API вы обычно можете найти способы обойти эти выбоины с производительностью.
Мое текущее мнение о состоянии ORM состоит в том, что я хочу, чтобы они делали как можно меньше, но при этом давали мне эффективность надежной библиотеки, которая заботится обо всех тонкостях доступа к данным. Другими словами, поскольку я не думаю, что они «достаточно хороши» и, возможно, никогда не будут использовать SQL в качестве серверной части, я хочу сохранить контроль на уровне «голого железа», и я перейду к написанию SQL с помощью рука без колебаний во многих случаях, независимо от ORM, потому что я знаю конкретный способ, которым я хочу, чтобы данные запрашивались для моих конкретных потребностей.
Очевидно, что это более хрупкий подход к кодированию, чем если бы вы неукоснительно использовали ORM, как это было задумано, поэтому в результате вы должны быть особенно внимательными с точки зрения модульного тестирования, SQL-инъекций и надлежащего разделения проблем. Итак, подытоживая, я согласен с Эшем, хотя это не означает, что он согласен со мной :)
[update] это больше не действует, дизайн этого проекта был изменен [/ update]
В нашем проекте с открытым исходным кодом Bunian мы пришли к выводу, что Business Objects (весь компонент) является ядром системы, и все должно вращаться вокруг него, включая этот уровень доступа к данным.
Компонент Business будет диктовать другим, что ему нужно, подразумевая это через itnerfaces. Например, у бизнес-объекта Person будет член интерфейса с именем IRepositoryForPerson, этому члену будет назначен экземпляр через контейнер внедрения зависимостей при необходимости.
Для получения дополнительных сведений ознакомьтесь с моим сообщением в блоге здесь:
http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design/
и проверьте здесь код Буниана (хотя он пока любительский):
http://www.codeplex.com/Bunian
Конечно, с этим подходом появятся новые вещи, такие как жизненный цикл сеанса доступа к данным (например, если вы используете NHibernate). но это будет для другого вопроса, я думаю :)
я надеюсь, вы найдете это полезным
