Хотя это субъективный вопрос, как новый пользователь NHibernate, мне любопытно, почему вы выбираете Fluent vs традиционное XML-сопоставление.
С моей точки зрения, когда я впервые работал с NHibernate, я использовал интерфейс Fluent, но столкнулся с некоторыми препятствиями и с трудом нашел подходящую документацию для интерфейса Fluent для чего-либо, кроме "игрушечного приложения", поэтому я научился обрабатывать их через XML.
Со временем я понял, что большую часть своей работы я прочитал на стороне XML, и понял, что это было не так ужасно, как я думал. Поэтому для меня лично это был плохая документация и не наблюдал значительную экономию времени кодирования.
Если говорить, может быть какое-то огромное преимущество/недостаток, которого я пропускаю, и мне бы очень хотелось услышать некоторые мнения от людей, у которых больше опыта работы с этими инструментами.
Безопасность и рефакторинг во время компиляции (переименование классов, свойств) являются одним из преимуществ, которые вы получаете от плавных сопоставлений. Использование одного языка (С# или VB.NET) для записи сопоставлений, программный код и доступ к данным - еще одно преимущество.
Для меня большой особенностью в Fluent является Automapper.
Я могу определить мою модель домена, используя классы POCO (в основном), не беспокоясь о неприятных подробностях того, как они будут сопоставлены таблицам в реляционной базе данных.
Как разработчик OO долгое время, а иногда и разработчик БД, мне гораздо удобнее заниматься дизайном в стиле OO. Я также считаю, что это позволяет мне работать на более высоком, более мощном уровне абстракции.
Automapping также делает текущие изменения в модели домена менее сложными.
Ваши клиенты только что сказали вам в последнюю минуту, что хотят добавить в базу четыре новых столбца?
Нет проблем - добавьте четыре новых свойства в связанный POCO (4 строки кода) и переназначьте.
Усиливает боль от постоянно меняющихся требований, которые являются фактом жизни во многих проектах.
Я добавлю причину, которая очень важна для создания пользовательских функций на основе общей базы кода:
С уверенностью вы можете переопределить сопоставления, чтобы добавить новое поле. Изменения в существующих (суперклассах) отображениях автоматически включаются в настройку/ветвь. Я был вынужден использовать Fluent, чтобы избежать сохранения отдельного файла .hbm/xml для каждого клиента. Рад, что я сделал:)
Как и много программного обеспечения с открытым исходным кодом, эта библиотека была доступна для общественности, прежде чем многие функции были готовы к производству. В зависимости от версии FluentNhib, с которой вы работали, некоторые функции могут вообще не выполняться. Например, когда я начал работать с ним, составные клавиши еще не были реализованы, и я нашел камень преткновения после камнем преткновения.
Но продукт превратился в отличный инструмент. Это довольно полно, по сравнению с xml, и предоставляет все преимущества, которые уже наметили другие.