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