FluentNHibernate or port to NHibernate mapping by code

Question

I have several projects using NH and FNH to generate the mappings (some Fluent some Automapped). There are still some bugs and missing features i need, but it seems that FNH could die because of mapping-by-code integrated into NHibernate.

Question: Contribute to FNH or to migrate the mappings to mapping-by-code or confORM and fixing problems/implementing features there?

Button

Answer 1

At our office, we have been using NHibernate for 3 years now. We've been thinking about making a move to Fluent Nhibernate but never made the move. Using hbm.xml files was still the easiest to debug/alter. Two common problems of those xml files are that they are all validated during the creating of the sessionfactory and they are not refactor-safe.

Due to a bug I had to update a newer release of NHibernate (we were using NHib 2.1.2GA) and when I implemented 3.2GA we also were handed the ability to use loquacious mappings (mapping by code). I decided to use Loquacious over Fluent because I don't have a dependency to another project (Fluent) and the fact that NHibernate won't be shipped if mapping by code is broken.

Be aware though, that Loquacious mapping isn't complete either. While I was mapping everything by code, I found out basic stuff like property-ref wasn't always implemented. Thus even though it's shipped, it's not 100% complete. And while this will not come as a shocker, it has bugs. yes. really. ;-)

for more info on (reported) bugs, check out the NHibernate bug database: https://nhibernate.jira.com/browse/NH

Hope this helps. Regards, Ted

Monniemono

this helps a but. So i will delay the move as long as i can, but there are still pending issues for me hanging around and we are going to produce prototypes of a legacy db mapped with FNH soon, so I'll either have to fix the issues, work around them or migrate (and fix). – Button

perhaps you can tell me what the stuff is you're missing in Fnh? maybe I can tell you if its missing in Loquacious too... – Monniemono

FNH 1.2 is missing equivalen of <list-index base="1">, FNH 1.3 alpha has bug with more than one Keycolum in joinedsubclass. And can i map nonexistant defaultproperties like in elegantcode.com/2009/07/13/…? – Button

inserting fields into the database without having properties in your domain isn't possible unless you use a DTO or something likewise. If you check my profile, you will see I have a simular question which is still unanswered. I already know the answer though. – Monniemono

.. and your list column problem can be mapped using NH 3.2 mapping by code for instance: List(x => x.YourCollectionPropertyHere, map => { map.Key(k => k.Column("KeyColumnInDetailTableHere")); map.Index(i => { i.Column("IndexColumnNameHere"); i.Base(1); }); }, r => r.OneToMany(x => x.Class(typeof(DetailClassHere)))); – Monniemono

how do i specify the equivalent of <joined-subclass><key><column /><column /><column /></key> in mapping by code? cant figure it out – Button

Answer 2

thx to @TedOnTheNet i will continue to use and contribute to FNH, because it will take a while until mapping-by-code reaches FNH in some areas

• Automapping
• Fluent API tells a lot better which possibilities there are
• far more verbose mappings

• .Database(SQLiteConfiguration.Standard.InMemory()) is still easier to figure out than

  .DataBaseIntegration(db =>
  {
      db.ConnectionString = ???;
      db.Dialect<SQLiteDialect>();
      db.Driver<???>();
  });
  

and some features:

• CompositeId and Table per Subclass
• default values for legacy columns
• property refs

Update: some features from hbm.xml (and FluentMapping) will not be possible at all with mapping by code:

• default values for legacy columns: database column to constant value without the need for a property in the entity class with mapping by code
• query only properties/collections: http://ayende.com/blog/4054/nhibernate-query-only-properties

Button

Perhaps you could accept TedOnTheNet's answer - I'm sure he'd appreciate the rep boost – Gastongastralgia

Answer 3

NH 3.2 does not have anything remotely equivalent to FNH's Automapping, as far as I can tell. (For me, that would be a dealbreaker).

Edit

The FNH Automapper can deal with most of the common patterns in an object model, such as inheritance, one-to-many relationships, self-referencing, etc - without requiring any help from the programmer. So far, pure NH has not achieved this level of automation.

Also, James Gregory has publicly stated that he will continue to develop FNH, at least in the near term. (Think I saw this on the FNH Google group a few months back, but I'm not sure exactly where).

Gastongastralgia

not completely true see fabiomaulo.blogspot.com/2011/04/… – Button

@Button - I looked at your link - it describes "Mapping By Convention", and Fabio basically says in the first couple of paragraphs that "some people call this automapping, but I don't". FNH also does mapping by convention, but FNH's automapping provides another level on top of that. The programmer just has to tell the Automapper which assemblies contain the POCO classes to map, and it does the rest. It's much more convenient, but just as powerful, because you can also add your own conventions or overrides for special cases. So, I stand by my answer, but think I'll add some more detail. – Gastongastralgia

i wanted to express that with "not completly", but you are right FNH Automapping is far easier. I used it in a production app and am really happy with the results. – Button