Ручная DAL & BLL по сравнению с ORM

Недавно я принял решение использовать 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, но есть люди, которым он нравится, и они не будут использовать ничего другого.

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

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

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

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

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

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

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

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

Пока в деловой мир не пришли ОО-ребята.

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

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

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

и вы избежите проблем с производительностью (например, ваш уровень ORM принимает сотни запросов, чтобы сделать то, что он должен делать в одном).

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

и вы избежите проблем с производительностью (например, ваш уровень ORM принимает сотни запросов, чтобы сделать то, что он должен делать в одном).

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

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

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

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

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

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

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

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

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

Я использую полужирный шрифт для 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 классами можно многое!

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