0

I have a set of Fluent NHibernate conventions most of which are database independent. However, there are a couple which are DBMS dependent such one for string properties:

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

Really I just use a convention like this one for DB generation (i.e. objects first development). This works all well and good for Oracle, but I then want do unit testing using an in-memory SQLite DB and obviously this convention wont work, as SQLite has no VARCHAR2 type.

Does anyone have any good advice or references on how they configure Fluent NHibernate in such circumstances.

At the moment I'm thinking along the lines of having a generic set of conventions that are database independent and then having the dependent ones in a sub directory/namespace. I would then have some kind of configuration that allows me to specify a custom ITypeSource component which would pick up all the generic conventions as well as the ones associated to the specific DBMS e.g. SqlConventionTypeSource, OracleConventionTypeSource...

Kind regards, Ryan.

Ryan.Bartsch
  • 3,698
  • 1
  • 26
  • 52

1 Answers1

0

You generally set up your conventions (as well as the rest of your fluent configuration) in the executable.

That means you'll have a different fluent configuration in your GUI, your unit tests, and anything else that happens to be consuming your ISession/ISessionFactory based services.

It sounds to me like you've hard-coded your configuration and are now trying to figure out how to get that "configurator" to act differently depending on some information about the environment.

A much simpler way would be to create your configuration at the top level and provide it as a dependency to whatever needs it. That way you're not shoehorned into the same code path from different environments.

Whatever it is that depends on NHibernate, set it up to accept an ISession or ISessionFactory as a constructor argument or property setter. Then you won't have this issue. You can even mock it for tests that don't actually need to query the data store.

Of course you can still set up whatever class creates the FNH config to be configurable in itself, and use conditional statements in the config lines. But usually a FNH config is so few lines of code to begin with, it hardly seems worth it. Just create totally separate configurations for SQL Server, Oracle, SQLite, etc. That way you won't have to constantly maintain it every time you make a minor change.

Aaronaught
  • 120,909
  • 25
  • 266
  • 342
  • Thanks for the response Aaronaught. – Ryan.Bartsch Oct 31 '11 at 06:34
  • FYI; I use the Castle.Facilities.NHibernateIntegration library to configure NHibernate with Windsor IoC. This way all my services/presenters that use NHibernate can be created with an ISessionManager as a required/optional class dependency. When I resolve a service, Windsor will inject the ISessionManager concrete implementation. Basically, I dont really need to worry too much about session management (e.g. open-session-per-request) using the facility and it enables me to do good unit testing bu mocking the ISessionManager. – Ryan.Bartsch Oct 31 '11 at 06:34
  • I can modify the default configuration of the session factory via the facilities IConfigurationBuilder interface, where I configure the NHibernate session factory fluently using auto mapping with conventions. I need to tell the FNH AutoPersistenceModel where to find the conventions, which are a good candidates for re-use given they are fairly complex, well defined, and unlikely to ever change. This gets back to my original issue, whereby some of my conventions are DB specific (i.e. those used to generate the schema). – Ryan.Bartsch Oct 31 '11 at 06:34
  • @Ryan: This seems like it should be a non-issue if you're using dependency injection. Are you actually using the IoC to inject, or are you relying on some kind of singleton/service-locator pattern? You should be able to create a *different* `ISessionManager` implementation specifically for your tests, and pass that in to whatever needs to be tested. – Aaronaught Oct 31 '11 at 23:34