Вы бы использовали NHibernate для проекта с устаревшей базой данных, которая частично находится вне вашего контроля?

Question

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

Почему я спрашиваю?

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

Второе: недавно у меня была беседа с кем-то, кто работал с Hibernate (jep, без 'N' до Hibernate). Он сказал мне, что фреймворки ORM сейчас довольно продвинуты и поддерживают Hibernate. Поскольку я не интересовался NHibernate, я не отслеживал последние события.

Может, мне пора переосмыслить свой ответ или нет?

Answer 1

iBatis, безусловно, легко сопоставить объекты с устаревшими системами баз данных.

В последнее время NHibernate 1.2 и 2.0 имеют набор функций, который может заставить вас переосмыслить iBatis.

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

NHibernate может использовать хранимые процедуры для операций CRUD над объектами, а также представления базы данных.

Коллекции могут быть пользовательскими хранимыми процедурами или запросами SQL. Коллекции могут использовать атрибут property-ref, если отношение внешнего ключа не отображается непосредственно на первичный ключ на другой стороне.

Некоторые из этих функций могут снизить производительность / мощность nhibernate, т. Е. Отложенная загрузка с помощью свойства-ref не работает (вообще?), Но в большинстве случаев для этого есть причины.

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

Сообщество Nhibernate выглядит намного богаче, чем iBatis. Я в обоих списках, и объем поддержки NHibernate довольно велик по сравнению с группой iBatis. Так что поддержка должна быть проще.

Также для NHibernate растет количество инструментов для сторонних разработчиков. Такие вещи, как NHibernate Profiler, Nhibernate Query Analyzer, NHibernate Contrib, Fluent NHibernate и многие другие.

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

И чтобы ответить на вопрос, да, мы используем NHibernate с устаревшими базами данных, которые имеют ужасные отношения, составные ключи, разорванные отношения. У нас также есть небольшой объем кода на основе iBatis. Мы больше не пишем код iBatis.

Answer 2

Да, рассмотрим NHibernate. Это золотой стандарт по причине. Я слышал, что iBATIS поддерживает сумасшедшие возможности отображения, но с IUserType от NHibernate вы можете отображать что угодно, даже действительно странные столбцы.

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

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

Я думаю, что вы окажете плохую услугу своим клиентам, если вы по крайней мере не заметите NHibernate.

Answer 3

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

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