ORM (Linq, Hibernate ...) действительно так полезен?

Question

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

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

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

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

ОБНОВЛЕНИЕ: ОК, это двойная :-) Я нашел это в конце концов:

ORM против уровня доступа к данным, закодированного вручную

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

• Hibernate обращается ко многим функциям, на код которых у вас уйдут месяцы и годы.

Answer 9

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

Answer 10

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