Является ли ORM (Linq, Hibernate ...) действительно полезным?

Question

Я играл с некоторыми LINQ ORM (LINQ непосредственно на SQL), и я должен признать, что мне нравятся его выразительные способности. Для небольших приложений, подобных утилитам, он также работает довольно быстро: выпадающий SQL-сервер на какой-то поверхности, и вы настроены на linq.

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

Мой, честный - я новичок в ORM - вопрос: какое большое преимущество ORM над написанием достойного DAL вручную?

(похоже, двойной, не мог найти его, хотя)

UPDATE: OK его двойной :-) Я нашел его сам в конце концов:

ORM vs Handcoded Data Access Layer

Answer 1

Я использовал JPA в проекте, и сначала я был очень впечатлен. Простите, я все это время спасал в написании SQL! Постепенно, однако, я немного разочаровался.

1. Сложность определения таблиц без суррогатных ключей. Иногда нам нужны таблицы, в которых нет суррогатных ключей. Иногда нам нужен многоколоночный первичный ключ.У TopLink были трудности с этим.
2. Форсированные отношения структуры данных. JPA использует аннотации для описания взаимосвязи между полем и контейнером или ссылочным классом. Хотя это может показаться превосходным на первом сайте, что вы будете делать, когда вы ссылаетесь на объекты по-разному в приложении? Скажем, например, вам нужны только конкретные объекты, которые ссылаются на конкретные записи на основе некоторых конкретных критериев (и он должен быть высокопроизводительным без ненужного распределения объектов или поиска записей). Усилия по модификации классов Entity почти всегда превышают усилия, которые существовали бы, если бы вы никогда не использовали JPA в первую очередь (предполагая, что вы вообще добиваетесь того, чтобы JPA выполняла то, что вы хотите).
3. Кэширование. JPA определяет понятие кешей для ваших объектов. Следует помнить, что база данных имеет свой собственный кеш, обычно оптимизированный вокруг минимизации чтения дисков. Теперь вы дважды кэшируете свои данные (игнорируя несохраненную кучу GC). Как это может быть преимуществом, это вне меня.
4. Данные! = Объекты. Для высокопроизводительных приложений извлечение данных из БД должно выполняться очень эффективно. Форсирование создания объектов не всегда хорошо. Например, иногда вам могут понадобиться массивы примитивов. Это около 30 минут работы для опытного программиста, работающего с прямым JDBC.
5. Производительность, отладка. Гораздо сложнее оценить производительность приложения со сложными вещами, происходящими в подсистеме (под-оптимальной, автогенерированной) кеширования, что еще больше усугубляет ресурсы проекта и бюджеты.

Большинство разработчиков на самом деле не понимают проблему несоответствия импеданса, которая всегда существовала при сопоставлении объектов с таблицами. Этот факт гарантирует, что JPA и друзья, вероятно, получат значительный (кашлевой) успех в обозримом будущем.

Answer 2

• Strong-типирование
• Не нужно писать DAL самостоятельно => экономия времени
• Не нужно писать код SQL самостоятельно => less error-p rone

Answer 3

Я использовал Hibernate в прошлом, чтобы динамически создавать довольно сложные запросы. Логика, связанная с созданием соответствующего SQL, была бы очень трудоемкой для реализации, по сравнению с логикой для построения соответствующего Criteria. Кроме того, Hibernate знал, как работать с различными базами данных, поэтому мне не нужно было вставлять какую-либо логику в наш код. Разумеется, нам пришлось тест на разные базы данных, и мне нужно было написать расширение для обработки «похожих» запросов соответствующим образом, но затем оно выполнялось без SQL Server, Oracle и HSqldb (для тестирования).

Существует также тот факт, что это больше кода, который вам не нужно писать, что всегда приятно. Я не могу сказать, что я использовал LINQ to SQL в любом большом, но где я использовал он для «быстрого и грязного» веб-сайта (очень маленький, редко обновляемый, мало пользы от абстракции полного слоя), это было прекрасно.

Answer 4

Переносимость между различными поставщиками db.

Answer 5

Мой, честный - я новичок в ORM - вопрос: что такое большой прогресс ORM над написанием достойного DAL вручную?

Не все программисты готовы или даже способны написать «достойный DAL». Те, кто не может испугаться или просто испугался, просто считают LINQ или любой другой ORM благословением.

Я лично использую LINQ для управления коллекциями кода из-за его выразительности. Он предлагает очень компактный и прозрачный способ выполнения некоторых общих задач в коллекциях непосредственно в коде.

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

С LINQ/ORM также может быть связано с задержкой для сайтов с высоким трафиком (так как каждый входящий запрос должен быть скомпилирован снова). Хотя я должен признать, что я не вижу никаких проблем с производительностью в SO.

Вы также можете рассмотреть возможность ожидания Entity Framework v2. Он должен быть более мощным, чем LINQ (и, надеюсь, не так уж плохо, как v1 (по мнению некоторых людей)).

Answer 6

Прозрачная настойчивость - изменения сохраняются (и каскадно), без необходимости звонить Save(). На первый взгляд это кажется кошмаром, но как только вы привыкнете к работе с ним, а не против него, ваш код домена может быть полностью освобожден от проблем с сохранением. Я не знаю ни одного ORM, кроме Hibernate/NHibernate, который может это сделать, хотя могут быть некоторые ...

Answer 7

Ну, для меня это очень важно, когда вам не нужно изобретать/воссоздавать колесо каждый раз, когда мне нужно для внедрения новой модели домена. Это намного эффективнее использовать, например, nHibernate (мой ORM выбор) для создания, использования и поддержки уровня доступа к данным.

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

В настоящее время я начинаю с домена. Я моделирую его в UML, и большую часть времени я могу генерировать все из этой модели, включая схему базы данных. Нужно несколько настроек здесь и там, но с моей текущей настройкой я получаю 95% работы с доступом к данным, сделанным в кратчайшие сроки. Время, которое я сохраняю, я могу использовать для точной настройки частей, которые нуждаются в настройке. Мне редко приходится писать любые SQL-запросы.

Это мои два цента. :-)

Answer 8

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

Answer 9

Лучший способ ответить на вопрос - понять, какие именно библиотеки, подобные Hibernate, совершают от вашего имени. В большинстве случаев абстракции существуют по какой-то причине, часто для того, чтобы сделать некоторые проблемы менее сложными, или в случае, когда Hibernate является почти DSL для выражения некоторых концепций устойчивости простым образом.

• Можно легко изменить стратегию выборки для коллекций, изменив аннотацию, а не записывая много кода.

• Hibernate и Linq проверены и испытаны многими, у вас мало шансов на достижение этого качества без большого количества работы.

• Hibernate адресует множество функций, которые потребуют от вас месяцев и лет для кодирования.

Answer 10

Кроме того, хотя в документации JPA указано, что составные клавиши поддерживаются, она может быстро стать очень сложной. Вы можете легко потратить часы (дни?), Пытаясь получить что-то очень простое. Если JPA действительно упростит ситуацию, разработчики должны быть освобождены от слишком многого размышления об этих деталях. Это не так, и нам остается понять два уровня абстракции: ORM (JPA) и JDBC. Для моего текущего проекта я использую очень простую реализацию, которая использует защищенный пакетом static get «конструктор», который принимает ResultSet и возвращает объект. Это примерно 4 строки кода для каждого класса, плюс одна строка кода для каждого поля. Это просто, высокопроизводительно и довольно эффективно, и я сохраняю полный контроль. Если мне нужно обращаться к объектам по-разному, я могу добавить еще один метод, который читает разные поля (например, оставив остальные нули). Мне не нужна спецификация, которая сообщает мне, «как должны выполняться ORM (!)». Если мне требуется кэширование для этого класса, я могу реализовать его точно по мере необходимости.