Я использовал реализацию активной записи Castle Project с NHibernate для личного проекта. Проект никогда не развертывался, отчасти из-за моей неспособности работать с выбором ORM, который я сделал.
Причина, по которой я решил использовать ORM, заключалась в том, что я хотел иметь возможность переключаться с SQL Server на MYSQL без изменения своего кода. В реальных проектах решение об использовании SQL-сервера уже принято за меня, и проще просто записывать слои данных традиционным трехуровневым способом, когда вы знаете, что база данных не изменится.
Но для личных проектов я использую виртуальный хостинг, и MySQL - более дешевое решение.
Причина, по которой я пошел с Каслом, заключалась в том, что им было очень легко пользоваться. С помощью плагина activewriter для Visual Studio я смог сгенерировать свои классы и базу данных, используя конструктор (вроде как linq to SQL designer), и он, казалось, хорошо вписывался в мою ментальную модель того, как ORM должен диктовать архитектуру вашего приложения. .
Проблема с ORM, с которой я столкнулся, заключалась в том, что я не смог найти информацию о том, как правильно его оптимизировать. Он делал очень большие звонки в базу данных. (SQL-запрос, сгенерированный для получения пользователя, составлял 1 МБ текста, когда я его регистрировал.)
Итак, используя ORM, я сэкономил много времени на начальном этапе, но натолкнулся на стену, когда попытался исправить проблему с каркасом, генерирующим слишком много SQL. (Над которой я все еще медленно работаю).
Несмотря на то, что я не нашел идеальное решение, я все равно попробовал бы ORM для других личных проектов, потому что это только я, и я хочу тратить свое время на забавный код, а не на датейлеры.
Однако на работе я, вероятно, не слишком поспешил бы предложить использовать ORM до того, как я стал экспертом (может быть, после того, как я получил несколько рабочих личных проектов за плечами).