Какие существуют причины для использования NHibernate?

Question

Для тех людей, которые используют NHibernate и подобные вещи, почему вы его используете? Мне проще писать SQL вручную.

Answer 1

Продуктивность и кросс-база данных переносимости - две причины. Hibernate/NHibernate или другие ORM позволяют легко сериализовать объекты в/из базы данных без необходимости вручную обрабатывать (и поддерживать) множество операторов SQL, чтобы сделать именно это. Я не знаю о вас, но писать и хранить тонны CRUD-запросов, актуальных для сотен объектов в нашей системе, - это не моя идея веселья, а также хорошее использование времени разработчика! Я не уверен, что NHibernate имеет аналогичный механизм, но плагин Hibernate Synchronizer для Eclipse действительно фантастичен: возьмите файл сопоставления и сделайте объекты и DAO автоматически. Хорошая вещь!

Эксплуатация (в кешках L1 и L2) - еще одна причина - хотя, конечно, вы можете, конечно, написать костяной код findAll(), который делает это спорным, но в целом они потратили много времени и усилий на это , поэтому это больше кода, который вам не нужно изобретать самостоятельно.

Теперь, конечно, есть нетривиальная кривая обучения для N/Hibernate, но, как и большинство вещей, когда вы ее получите, вы будете удивляться, как вы жили без нее.

Тем не менее, ОРМ не являются серебряной пулей (хотя они очень хороши, как правило), и они не подходят для всех обстоятельств. Мы все еще пишем SQL для сложных или высоко оптимизированных запросов. Тем не менее, разработчики моей команды клянутся Hibernate и, вероятно, восстанут, если мы вернемся к написанию прямого SQL во всем мире.

Answer 2

This question, вероятно, поможет вам, есть a lot more связанные с ОРМ вопросы по SO уже, , которые в значительной степени покрывают NHibernate, как это «народный выбор» вместе с дозвуковой скоростью и Linq-To-Sql.

Короче:

• Это очень зрелый
• Он поддерживает почти все РСУБД
• Это имеет большое сообщество и много разработчиков на проекте
• Он имеет мощную обработку запросов. После того, как вы используете HQL для коллекций, вы не хотите, чтобы вернуться к присоединяется
• Она имеет очень тонкий уровень определения объекта, для коллекции частичном

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

Answer 3

Что вы подразумеваете под простейшим? Предположим, что вы выполнили стандартную настройку Order-> Line Item-> Product. Если я хочу найти все заказы с позицией для продукта, я могу написать это в HQL: выбрать заказ из заказа, LineItem lineItem, продукт продукта где product.id =: id и product.id = lineItem.product .id и lineItem член заказа.lineItems

SQL для этого намного более беспорядочно. Особенно, если у вас есть несколько сводных таблиц в миксе и т. Д. Если SQL-код для фразы «член» стоит избегать. Так что SQL проще настроить, да в основном. Легче ли писать SQL? Не для какой-либо значительной объектной модели. Итак, что вы подразумеваете под этим?

Answer 4

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

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

Вы имеете в виду, что простой в строке SQL легче читать? Я бы сказал, что по мере того, как сложность вашего приложения возрастает, вам может быть гораздо труднее прочитать строки и строки SQL, v.s. анализ хорошо структурированной модели домена.

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

Если вы создаете футболку ... вам, вероятно, не нужен молоток.

Answer 5

Одна из причин использования NHibernate, о которой не упоминалось до сих пор, заключается в том, что использование NHibernate позволяет использовать Linq. Большинство людей согласны с тем, что Linq замечательный.

Вы не можете использовать Linq без слоя данных, который поддерживает Linq, и для этого обычно требуется ORM. Если вы собираетесь использовать ORM, чтобы использовать Linq, NHibernate - лучший выбор.

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

Как только вы решите, что не хотите писать еще один набор CRUD SQL, вы начинаете рассматривать ORM. Как только вы начнете рассматривать ORM, вы, скорее всего, получите NHibernate как лучший выбор.

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

Answer 6

Конечно, я бы использовал только продукт с хорошим коэффициентом зрелости по времени. nHibernate не установил хороший знак с момента его создания в 2001 году.

Изменения производятся непрерывно. Код трудно читать и понимать. Нет визуального дизайнера . Весь процесс кажется довольно сложным или посторонним.

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

nHibernate не был разработан профессиональными инженерами.