Вы бы использовали NHibernate для проекта с устаревшей базой данных, которая частично находится вне вашего контроля?
Для меня ответ на данный момент: нет, я бы использовал iBatis, потому что NHibernate-это боль, когда модель базы данных и объектная модель не синхронизированы. Если у меня не будет полного контроля над базой данных, мне придется много работать.
Почему я спрашиваю?
Ну, во-первых: я никогда не использовал NHibernate. Я просто знаю это с поверхности. Я читал о преимуществах iBatis для устаревших баз данных.
Второе: недавно у меня была дискуссия с кем-то, кто работал с Hibernate (Джеп, без "Н" перед гибернацией). Он сказал мне, что фреймворки ORM теперь довольно продвинуты и поддерживают гибернацию. Поскольку я не интересовался Нибернатом, я не следил за последними событиями.
Может быть, мне пора переосмыслить свой ответ, или нет?
3 ответа:
IBatis, безусловно, легко сопоставлять объекты с устаревшими системами баз данных.
В последнее время NHibernate 1.2 и 2.0 имеют набор функций, которые могут заставить вас переосмыслить iBatis.
NHibernate работает с составными ключами, которые часто встречаются в старых базах данных, с ними не всегда приятно работать, но для этого есть поддержка.
NHibernate может использовать хранимые процедуры для операций CRUD над сущностями, а также представления баз данных.
Коллекции могут храниться на заказ процедуры или SQL-запросы. Коллекции могут использовать атрибут property-ref, когда отношение внешнего ключа не сопоставляется непосредственно с первичным ключом на другой стороне.
Некоторые из этих функций могут отнять у производительности / мощности nhibernate, т. е. ленивая загрузка со свойством-ref не работает (вообще?), но в большинстве случаев для этого есть свои причины.
Другие моменты: (которые на самом деле не связаны с вашей устаревшей базой данных, но все же могут помочь решить, какую технологию выбрать выбор)
Сообщество NHibernate На выглядит гораздо богаче, чем iBatis. Я в обоих списках,и объем поддержки NHibernate довольно велик по сравнению с группой iBatis. Так что поддержка должна быть проще.
Также существует растущее количество инструментов contrib / 3rd party для NHibernate. Такие вещи, как NHibernate Profiler, NHibernate Query Analyzer, NHibernate Contrib, Fluent NHibernate, чтобы назвать несколько.
Может быть, вы можете расширить на какие преимущества вы верите iBatis в настоящее время имеет. NHibernate, безусловно, был довольно активен в последнее время и приобрел много новых функций, многие из которых действительно помогают в устаревших/трудно модифицируемых схемах.
И чтобы ответить на этот вопрос, Да, мы используем NHibernate с устаревшими базами данных, которые имеют ужасные отношения, составные ключи, сломанные отношения. У нас все еще есть небольшое количество кода, основанного на iBatis. Однако мы больше не пишем код iBatis.
Да, рассмотрим NHibernate. Это золотой стандарт не просто так. Я слышал, что iBATIS поддерживает сумасшедшие возможности отображения, но с помощью IUserType NHibernate вы можете отображать все, даже действительно странные столбцы.
@Ahmad, весь смысл ORM заключается в том, чтобы предотвратить тесную связь между вашими объектами и схемой. Если у вас есть эта проблема, вы делаете это неправильно.
Кроме того, в NHibernate есть множество опций для пользовательских запросов, свойств формул и сохраненных процедуры. HQL чрезвычайно мощный и гибкий критерий.
Я думаю, что вы окажете своим клиентам плохую услугу, если вы хотя бы не спайкнете NHibernate.
Я использую nHibernate в существующем приложении. Я использую его для всех новых разработок, у меня нет намерения переносить существующий материал, либо просто нет убедительной причины, но для нового материала в проекте он отлично работает.
Если вы собираетесь перенести код, то вы должны иметь возможность изменить базу данных, чтобы лучше соответствовать вашей модели домена, без особого влияния (в зависимости от того, насколько утечка вашей базы данных, т. е. кто к ней обращается). Изменение модели домена приведет к однако последствия применения.