FluentNHibernate or port to NHibernate mapping by

问题:

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?

回答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

回答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

回答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).