Руководство DAL & BLL против ORM

Question

Какой подход лучше: 1) для использования сторонней системы ORM или 2) , вручную введите код DAL и BLL работать с базой данных?

1) В одном из наших проектов мы решили использовать систему DevExpress XPO ORM и столкнулись с множеством небольших проблем, которые напрасно тратили наше время. И все же время от времени мы сталкиваемся с проблемами и исключениями, возникающими из этого ORM, и у нас нет полного понимания и контроля над этим «черным ящиком».

2) В другом проекте мы решили написать DAL и BLL с нуля. Хотя это подразумевало написание скучного кода много-много раз, но этот подход оказался более универсальным и гибким: мы имели полный контроль над тем, как данные хранятся в базе данных, как они были получены из нее и т. Д. И все ошибки могли быть исправлено прямым и простым способом.

Какой подход обычно лучше ? Может быть, проблема только в том, что мы использовали ORM (DevExpress XPO), и, возможно, другие ORM лучше (например, NHibernate)?

Стоит ли использовать ADO Entiry Framework ?

Я обнаружил, что DotNetNuke CMS использует свой собственный код DAL и BLL. А как насчет других проектов?

Я хотел бы получить информацию о вашем личном опыте : какой подход вы используете в своих проектах, какой предпочтительнее?

Спасибо.

Answer 1

Мой личный опыт показывает, что ORM обычно является пустой тратой времени.

Сначала рассмотрим историю, стоящую за этим. Еще в 60-х и начале 70-х у нас были эти СУБД, использующие иерархическую и сетевую модели. Использовать их было немного сложно, так как при их запросе вам приходилось иметь дело со всей механикой поиска: переходите по ссылкам между записями повсюду и разберитесь с ситуацией, когда ссылки не были ссылками, которые вы хотели ( Например, указали в неправильном направлении для вашего конкретного запроса). Итак, Кодд придумал идею реляционной СУБД: укажите отношения между вещами, скажите в своем запросе только то, что вы хотите, и позвольте СУБД разобраться в механике ее получения. Как только у нас было несколько хороших реализаций, ребята из базы данных были в восторге, все переключились на это, и мир был счастлив.

Пока парни из OO не пришли в мир бизнеса.

ОО парни обнаружили это несоответствие импеданса: СУБД, используемые в бизнес-программировании, были реляционными, но внутренне ОО парни хранили вещи со ссылками (ссылками) и находили вещи, выясняя детали, по каким ссылкам они должны были следовать и следуя им. их. Да, это по сути иерархическая или сетевая модель СУБД. Таким образом, они приложили много (часто гениальных) усилий для наложения иерархической / сетевой модели на реляционные базы данных, случайно отбрасывая многие преимущества, предоставляемые нам СУРБД.

Мой совет - изучить реляционную модель, спроектировать свою систему вокруг нее, если она подходит (как это часто бывает), и использовать мощь своей СУБД. Вы избежите несоответствия импеданса, как правило, вам будет легко писать запросы, и вы избежите проблем с производительностью (например, ваш уровень ORM принимает сотни запросов для выполнения того, что он должен делать в одном).

Существует определенное количество «сопоставлений», которые необходимо выполнить, когда дело доходит до обработки результатов запроса, но это будет довольно легко, если вы подумаете об этом правильно: заголовок отношения результата сопоставляется с класс, и каждый кортеж в отношении является объектом. В зависимости от того, какая дополнительная логика вам нужна, может стоить или не стоить определять реальный класс для этого; может быть достаточно просто обработать список хэшей, сгенерированных из результата. Просто пройдите и обработайте список, сделайте то, что вам нужно, и все готово.

Answer 2

Возможно, и то, и другое подходит. Вы можете использовать такой продукт, как SubSonic. Таким образом, вы можете спроектировать свою базу данных, сгенерировать свой DAL-код (удаляя все эти скучные вещи), использовать частичные классы, чтобы расширить его собственным кодом, использовать хранимые процедуры, если хотите, и, как правило, выполнять больше работы.

Вот что я делаю. Я считаю, что это правильный баланс между автоматизацией и контролем.

Я бы также отметил, что я думаю, что вы на правильном пути, пробуя разные подходы и выясняя, что лучше всего подходит для вас . Я думаю, что это в конечном итоге источник вашего ответа.

Answer 3

Недавно я принял решение использовать Linq to SQL в новом проекте, и мне это очень нравится. Он легкий, высокопроизводительный, интуитивно понятный, и в нем есть много гуру из Microsoft (и других), которые пишут об этом в блоге.

Linq to SQL работает путем создания слоя данных объектов c # из вашей базы данных. DevExpress XPO работает в обратном направлении, создавая таблицы для ваших бизнес-объектов C #. Entity Framework должен работать в любом случае. Я - специалист по базам данных, поэтому идея создания инфраструктуры для базы данных для меня не имеет особого смысла, хотя я вижу привлекательность этого.

Мой проект Linq to SQL - проект среднего размера (сотни, может быть, тысячи пользователей). Для небольших проектов иногда я просто использую объекты SQLCommand и SQLConnection и общаюсь напрямую с базой данных, с хорошими результатами. Я также использовал объекты SQLDataSource в качестве контейнеров для моего CRUD , но они кажутся неуклюжими.

DAL имеют больше смысла, чем больше ваш проект. Если это веб-приложение, я всегда использую какой-то DAL, потому что они имеют встроенную защиту от таких вещей, как атаки SQL-инъекций, лучшая обработка нулевых значений и т. Д.

Я обсуждал вопрос об использовании Entity Framework для моего проекта, поскольку Microsoft заявляет, что в будущем это будет их универсальное решение для доступа к данным. Но EF кажется мне незрелым, и если вы будете искать в StackOverflow Entity Framework, вы найдете несколько человек, которые борются с небольшими, тупыми проблемами. Я подозреваю, что версия 2 будет намного лучше.

Я ничего не знаю о nHibernate, но есть люди, которые любят его и больше ничего не будут использовать.

Answer 4

Вы можете попробовать использовать NHibernate. Так как это с открытым исходным кодом, это не совсем черный ящик. Он очень универсален, и у него есть много точек расширения, чтобы вы могли подключить свои собственные дополнительные функции или функции замены.

Комментарий 1:

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

Комментарий 2:

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

Скорее всего, вы обнаружите, что можете осуществлять очень детальный контроль над стратегиями доступа к данным, которые использует NHibernate, настолько, что NHibernate, вероятно, будет отличным выбором и для ваших сложных случаев. Однако в любом конкретном контексте вы можете использовать NHibernate или не использовать его (в пользу более настраиваемого кода DAL), как вам нравится, потому что NHibernate старается не мешать вам, когда он вам не нужен. Таким образом, вы можете использовать пользовательский DAL или DevExpress XPO в одном классе (или методе) BLL, а в другом - NHibernate.

Answer 5

Я предлагаю вам использовать Code Smith Tool для создания Nettiers, это хороший вариант для разработчика.

Answer 6

Я использовал Bold для Delphi уже четыре года. Это здорово, но больше не доступно для продажи и в нем отсутствуют некоторые функции, такие как привязка данных. ECO у преемника есть все это. Нет, я не продаю ECO-лицензии или что-то в этом роде, но мне просто жаль, что так мало людей понимают, что может сделать MDD (Model Driven Development). Способность решать более сложные проблемы за меньшее время и меньше ошибок. Это очень трудно измерить, но я слышал что-то вроде 5-10 более эффективных разработок. И поскольку я работаю с этим каждый день, я знаю, что это правда.

Может быть, какой-то традиционный разработчик, работающий с данными и SQL, скажет:

1. "А как насчет производительности?"
2. «Я могу потерять контроль над тем, какой SQL запускается!»

Ну ...

1. Если вы хотите как можно быстрее загрузить 10000 экземпляров таблицы, может быть лучше использовать хранимые процедуры, но большинство приложений этого не делают. И Bold, и ECO используют простые SQL-запросы для загрузки данных. Производительность сильно зависит от количества запросов к базе данных для загрузки определенного объема данных. Разработчик может помочь, сказав, что эти данные принадлежат друг другу. Загрузите их как можно эффективнее.

2. Реальные запросы, которые выполняются, могут, конечно, регистрироваться для выявления проблем с производительностью. И если вы действительно хотите использовать свой гипероптимизированный SQL-запрос, это не проблема, если он не обновляет базу данных.

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

Еще стоит попробовать ECO. Бесплатное использование неограниченное время, пока модель не более 12 классов. Вы можете многое сделать с 12 классами!

Answer 7

Как объясняют другие, есть фундаментальная проблема с ORM, которая делает его таким, что ни одно из существующих решений не делает очень хорошую работу, делая правильные вещи, большую часть времени. Это сообщение в блоге: Вьетнам компьютерной науки перекликается с некоторыми из моих чувств по этому поводу.

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

Answer 8

Я недавно принял участие в достаточно большом интересном проекте. Я не присоединился к нему с самого начала, и нам пришлось поддерживать уже реализованную архитектуру. Доступ к данным для всех объектов был реализован через хранимые процедуры и автоматически генерировал методы-оболочки в .NET, которые возвращали объекты DataTable. Процесс разработки в такой системе был действительно медленным и неэффективным. Мы должны были написать огромную хранимую процедуру на PL / SQL для каждого запроса, что можно выразить простым запросом LINQ. Если бы мы использовали ORM, мы бы реализовали проект в несколько раз быстрее. И я не вижу никаких преимуществ такой архитектуры.

Я признаю, что это просто не очень успешный проект, но я сделал следующий вывод: прежде чем отказаться от использования ORM, подумайте дважды, действительно ли вам нужна такая гибкость и контроль над базой данных? Я думаю, что в большинстве случаев это не стоит потраченных впустую времени и денег.