Почему Fluent NHibernate против hbm XML-файлов?

Question

Хотя это субъективный вопрос, как новый пользователь NHibernate, мне любопытно, почему можно было бы выбрать Fluent против традиционного сопоставления XML.

С моей точки зрения, когда я впервые работал с NHibernate, я использовал интерфейс Fluent, но столкнулся с некоторыми препятствиями и с трудом нашел подходящую документацию для интерфейса Fluent для всего, кроме «игрушечного приложения», поэтому я научился обрабатывать их через XML.

Со временем я понял, что большую часть своей работы выполняю на стороне XML, и понял, что это не так ужасно, как я думал. Так что лично для меня это был случай плохой документации и не видела значительной экономии времени на кодирование.

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

Answer 1

Безопасность во время компиляции и рефакторинг (переименование классов, свойств) - это одно из преимуществ, которые вы получаете от плавных отображений. Использование одного языка (C # или VB.NET) для написания отображений, программного кода и доступа к данным - еще одно преимущество.

Answer 2

• Имя во время компиляции и безопасность типов
• IntelliSense, чтобы показать вам, какие беглые методы доступны в любой точке
• Настраиваемые значения по умолчанию
• Automapper

Answer 3

Для меня большая особенность в Fluent - Automapper.

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

Как давний OO-разработчик и случайный разработчик БД, мне гораздо удобнее проектировать OO-модой. Я также считаю, что это позволяет мне работать на более высоком и мощном уровне абстракции.

Автоматическое сопоставление также делает текущие изменения в модели предметной области гораздо менее пугающими.

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

Нет проблем - добавьте четыре новых свойства в связанный POCO (4 строки кода) и переназначьте.

Снижает боль от постоянно меняющихся требований, которые являются фактом жизни во многих проектах.

Answer 4

Я добавлю причину, которая очень важна для создания пользовательских функций на основе общей базы кода:

Свободно вы можете переопределить сопоставления, чтобы добавить новое поле. Изменения в существующих (суперклассовых) сопоставлениях автоматически включаются в настройку / ветвь. Я был вынужден использовать Fluent, чтобы избежать ведения отдельного файла .hbm / xml для каждого клиента. Рад, что я сделал:)

Answer 5

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

Но продукт превратился в довольно хороший инструмент.Это довольно полная функция по сравнению с xml и предоставляет все преимущества, которые уже обрисованы другими.