Бизнес-объект DAL design

Question

При проектировании бизнес-объектов я пробовал несколько разных способов записи уровня доступа к данным. Некоторые из них работают лучше других, но я всегда чувствовал, что должен быть «лучший» способ.

Я бы просто хотел увидеть, как люди справлялись с DAL в разных ситуациях, и их мнение о том, как техника работает или не работает.

Answer 1

К сожалению, я не думаю, что существует «лучший способ», он слишком зависит от конкретной ситуации относительно того, какой подход вы используете DAL. Отличное обсуждение «современного искусства» - Patterns of Enterprise Application Architecture от Мартина Фаулера.

В главе 10 «Архитектурные шаблоны источников данных» говорится о большинстве наиболее часто используемых шаблонов для бизнес-приложений.

В общем, я нашел, что самый простой подход, который отвечает основным требованиям ремонтопригодности и адаптации, является лучшим выбором.

Например, в недавнем проекте был всего лишь простой «Шлюз данных строк». (Это были просто классы, созданные кодом для каждой соответствующей таблицы базы данных, включая методы для выполнения операций CRUD). Никаких бесконечных дебатов об ORM по сравнению с хранимыми процессами, он просто работал и хорошо выполнял требуемую работу.

Answer 2

Существует несколько распространенных шаблонов. 'The patterns of enterprise architecture' книга является хорошим ориентиром для них:

• Таблицы данные Шлюз
• Row Data Gateway
• Active Record Mapper
• данных

Если вы используете ORM, например, LLBLGen, вы получаете выбор самообслуживания или адаптера.

Answer 3

В настоящее время я полагаюсь на Billy McCafferty's NHibernate Best Practices article/sample code для многих приложений Web/WinForms. Это замечательно написанная статья, которая предоставит вам хорошую пробную архитектуру - в дополнение к обучению базовому NHibernate и TDD. Он пытается дать вам обзор его архитектурных и дизайнерских решений.

Он создает очень элегантный DAL, используя общие DataAccessObjects, которые вы можете расширить для каждого объекта домена - и его очень слабо связан с BL с использованием интерфейсов и DAOFactory. Я бы порекомендовал сначала взглянуть на BasicSample, особенно если вы раньше не работали с NHibernate.

Примечание. Эта статья в значительной степени зависит от NHibernate, но я думаю, что общий подход к ней может быть легко изменен в соответствии с другими ORM.

Answer 4

Если вы идете по маршруту NHibernate (ссылка на статью BTW от @Watson выше), то я настоятельно рекомендую вам проверить проект образца suvius-flamingo с помощью codebetter. У него очень приятный, сжатый примерный проект, в котором показаны действия MVC и NHibernate.

Вот suvius-flamingo link.

Answer 5

[обновление] это уже не действует, дизайн этого проекта был изменен [/ обновление]

В нашем проекте с открытым исходным кодом Bunian, мы пришли к выводу, что Business Objects (весь компонент) является ядром система, и все должно вращаться вокруг нее, включая этот уровень доступа к данным.

Бизнес-компонент будет диктовать другим то, что ему нужно, подразумевая, что через его внутренние поверхности. Например, бизнес-объект Лицо будет иметь член интерфейса, называемый IRepositoryForPerson, этому члену будет назначен экземпляр через контейнер впрыска зависимости, когда это необходимо.

Для получения более подробной информации проверить мой блог здесь:

http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//

и проверить код Bunian здесь (хотя это любительская еще):

http://www.codeplex.com/Bunian

Конечно там будет появление новых вещи с таким подходом, как жизненный цикл сеанса доступа к данным (например, если вы используете NHibernate). но это было бы еще вопрос, я думаю :)

я надеюсь, что вы найдете этот полезный

Answer 6

Я предполагаю, что вы имеете в виду писать DAL, который обращается SQL, так как это является наиболее распространенной частью сегодня. ONe, если самые большие проблемы при написании DAL для SQL - это часть ORM. То есть существует принципиальное несоответствие импеданса между программированием OO и схемами реляционных баз данных. Было много замечательных, успешных попыток написания ORM. Но все они страдают от той же проблемы, что и их польза: они абстрагируют вас от генерируемого SQL-кода. Почему это проблема, заключается в том, что производительность вашей базы данных является важной составляющей того, насколько хорошо ваша система работает в целом. Многие ORM (возможно, большинство) не только обладают нестандартной производительностью для многих стандартных запросов, но и фактически поощряют шаблоны использования, которые значительно ухудшают производительность (неоднократно пересекающиеся отношения в циклах, когда запрос коллекций является одним из распространенных примеров, что затрудняет урегулирование взаимоблокировок другой). Конечно, после изучения API ORM в деталях, вы обычно можете найти пути вокруг этих выбоин.

Мое текущее состояние ORM заключается в том, что я хочу, чтобы оно делалось как можно меньше, но при этом давало мне эффективность сплошной библиотеки, которая заботится обо всех гайках и болтах доступа к данным. Другими словами, поскольку я не думаю, что они «достаточно хороши» и, возможно, никогда не будут с SQL в качестве задней части, я хочу сохранить контроль на уровне «чистого металла», и я опустится до написания SQL без колебаний во многих случаях, независимо от ORM, потому что я знаю конкретный способ, которым я хочу, чтобы данные запрашивались для моих данных потребностей.

Это, очевидно, более хрупкий подход к кодированию, чем если бы вы религиозно использовали ORM, поскольку он был предназначен, поэтому вы должны быть более усердными с точки зрения модульного тестирования, SQL-инъекции и надлежащего разделения проблем , Итак, подытожим, я согласен с Эшем, хотя это не означает, что он/она согласен со мной :)