Конкретні конвенції для БД у Fluent NHibernate

У мене є безліч звичних конвенцій NHibernate, більшість з яких є незалежними від бази даних. Однак існує пара, яка є СУБД, залежною від такої для властивостей рядка:

Public Sub Apply(ByVal instance As IPropertyInstance) Implements IConvention(Of IPropertyInspector, IPropertyInstance).Apply
    instance.CustomSqlType("VARCHAR2(50 BYTE)")
End Sub

Дійсно, я використовую подібну конвенцію для генерації БД (тобто, перша розробка об'єктів). Це працює все добре і добре для Oracle, але тоді я хочу зробити тестування блоків за допомогою БД SQLite в пам'яті і, звичайно, ця конвенція не буде працювати, оскільки SQLite не має типу VARCHAR2.

Хто-небудь має які-небудь хороші поради або посилання на те, як вони налаштовують Fluent NHibernate за таких обставин.

На даний момент я думаю про те, щоб мати загальний набір умовностей, які є незалежними від бази даних, а потім мати залежні в підкаталозі/просторі імен. Тоді я мав би якусь конфігурацію, яка дозволить мені вказати користувальницький компонент ITypeSource, який би підбирав всі загальні конвенції, а також ті, які пов'язані з конкретною СУБД, наприклад SqlConventionTypeSource, OracleConventionTypeSource ...

З повагою, Райан.

0

1 Відповіді

Як правило, ви встановлюєте свої угоди (а також решту вільної конфігурації) у виконавчому файлі.

Це означає, що у вашому графічному інтерфейсі ви матимете іншу вільну конфігурацію, ваші модульні тести та все інше, що споживає ваші послуги на основі ISession / ISessionFactory .

Мені здається, що ви налаштували свою конфігурацію, і тепер намагаєтеся зрозуміти, як змусити "конфігуратора" по-різному діяти в залежності від інформації про навколишнє середовище.

Набагато простішим способом було б створити вашу конфігурацію на вищому рівні і забезпечити її як залежність від будь-якої потреби. Таким чином, ви не ввійшли в один і той же код з різних середовищ.

Незалежно від того, що залежить від NHibernate, налаштуйте його, щоб прийняти ISession або ISessionFactory як аргумент конструктора або встановлювач властивостей. Тоді ви не матимете цього питання. Можна навіть висміювати його для тестів, які фактично не потрібно запитувати в сховище даних.

Звичайно, ви все ще можете налаштувати будь-який клас, який створює конфігурацію FNH, щоб бути налаштованим сам по собі, і використовуйте умовні оператори в лініях конфігурації. Але зазвичай конфігурація FNH так мало рядків коду для початку, навряд чи варто. Просто створіть повністю окремі конфігурації для SQL Server, Oracle, SQLite і т.д. Таким чином вам не доведеться постійно підтримувати його кожного разу, коли ви робите незначні зміни.

0
додано
@Ryan: Це, здається, не має проблеми, якщо ви використовуєте ін'єкції залежності. Ви фактично використовуєте IoC, щоб ін'єктувати, або ви покладаєтеся на певний синглтон/сервіс-локатор? Ви повинні мати можливість створити іншу ISessionManager реалізацію, спеціально для ваших тестів, і передати її у те, що потрібно перевірити.
додано Автор Aaronaught, джерело
Дякуємо за відповідь Aaronaught.
додано Автор Ryan.Bartsch, джерело
FYI; Я використовую бібліотеку Castle.Facilities.NHibernateIntegration для налаштування NHibernate за допомогою Windsor IoC. Таким чином, всі мої служби/презентатори, які використовують NHibernate, можуть бути створені за допомогою ISessionManager як обов'язкова/необов'язкова залежність класу. Коли я вирішу службу, Windsor буде вводити конкретну реалізацію ISessionManager. В принципі, я дійсно не потрібно занадто турбуватися про керування сеансами (наприклад, відкритий сеанс-за-запит) за допомогою засобу, і це дозволяє мені робити хороше тестування блоку, знущаючись над ISessionManager.
додано Автор Ryan.Bartsch, джерело
Я можу змінити конфігурацію за замовчуванням фабрики сеансу за допомогою інтерфейсу IConfigurationBuilder, де я налаштовую заводський сеанс NHibernate, використовуючи автоматичне зіставлення з умовами. Мені потрібно сказати FNH AutoPersistenceModel де знайти конвенції, які є хорошими кандидатами для повторного використання, оскільки вони досить складні, добре визначені і навряд чи коли-небудь зміняться. Це повертається до моєї початкової проблеми, де деякі з моїх умов є специфічними для БД (тобто ті, що використовуються для створення схеми).
додано Автор Ryan.Bartsch, джерело