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

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

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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

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

Automapping также делает текущие изменения в модели домена менее сложными.

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

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

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

Ответ 4

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

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

Ответ 5

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

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