NHibernate определенно может сделать вашу жизнь проще. Обновления в вашей схеме базы данных, безусловно, будут проще, потому что, когда вы используете ORM, у вас нет API хранимых процедур, препятствующих рефакторингу вашей схемы базы данных для удовлетворения изменений в вашей бизнес-модели.
ИЛИ картографы имеют много предложений, и, к сожалению, их неправильно понимает значительная часть сообщества разработчиков и почти все сообщество администраторов баз данных.
Хранимые процедуры, как правило, предоставляют администратору базы данных больше возможностей для настройки производительности в базе данных, поскольку они могут свободно перезаписывать хранимый процесс, если он не изменяет его вывод. Однако, по моему опыту, хранимые процедуры редко переписываются из-за других проблем, которые могут возникнуть в результате (например, когда выполняется развертывание новой версии программного обеспечения, любые измененные версии существующих процедур будут перезаписывать оптимизированную версию, которая была изменена). администратором базы данных ... тем самым сводя на нет преимущества и создавая проблемы с обслуживанием и непредвиденными проблемами с производительностью.)
Еще одно серьезное заблуждение (и это в первую очередь из лагеря SQL Server ... У меня очень мало опыта работы с Oracle) заключается в том, что хранимые процедуры - это единственное, что можно скомпилировать и кэшировать план выполнения. Что касается SQL Server, любой параметризованный запрос может и, вероятно, будет скомпилирован и кэширован.
Преимущество картографов OR заключается в том, что они являются адаптивными ... с помощью хранимой процедуры вы пишете один оператор, который будет использоваться независимо от контекстуальных нюансов при выполнении этого запроса. LINQ to SQL обладает удивительной способностью генерировать самые эффективные запросы, которые я когда-либо видел, и часто бросает DBA в серьезный цикл. Я показал запросы DBA, сгенерированные L2S, которые были полны подзапросов и нетрадиционных вещей, которые были немедленно осмеяны. Однако, учитывая проблему, производительность (а именно, физическое чтение) запроса, написанного администратором базы данных, который предположительно был выше, в итоге оказалась значительно ниже (иногда в масштабе 30 физических чтений для L2S против 400 физических чтений для DBA.)
Другим недоброжелателем в отношении администраторов баз данных является то, что, поскольку ORM генерирует динамический SQL, у них нет возможности оптимизировать эти запросы. Напротив (и опять же, это ограничено SQL Server), SQL Server предлагает множество путей оптимизации (разбиение горизонтальной и вертикальной таблиц, распределение физических файлов по дискам для любой таблицы или представления, индексов и т. Д.), Которые могут быть принимается до того, как необходимость изменить запрос является необходимостью. Даже в случае необходимости изменения запроса в SQL Server 2005 и более поздних версиях предусмотрены руководства по планированию, которые позволяют умеренно настраивать любой запрос (сохраненный процесс, прямой SQL и т. Д.). В случае, если настройки запроса недостаточно, вы можете сопоставить любой конкретный запрос с полным запросом на замену, позволяя администратору БД настраивать запрос так, как ему необходимо (но в крайнем случае).
Существует много, много преимуществ, которые можно получить, используя OR mapper, и NHibernate является одним из лучших бесплатных (LLBLGen также очень хорош, но не бесплатен.) LINQ to Sql и Entity Framework являются некоторыми новыми предложения от Microsoft (L2S скоро будет заменен на EF 4.0 из .NET 4.0 framework ... который по крайней мере будет конкурировать, если не опережать, NHibernate.) Самым большим препятствием для принятия ORM обычно не является сам продукт ORM, ни его возможности или производительность. Самым большим препятствием обычно является убеждение вашего администратора баз данных (если вам повезло / не повезло ... зависит от вашего опыта ... иметь его), что ORM может повысить эффективность и снизить затраты на обслуживание без затрат на пути оптимизации для администратора баз данных.