My attempt to rewrite fluent nhibernate

[Paul Batum]

Today I checked in my current progress on a fluent nhibernate rewrite. I wrote a blog post with more information:
http://www.paulbatum.com/2008/12/fluent-nhibernate-rewrite.html

You can view the commit log here:
http://code.google.com/p/fluent-nhibernate/source/detail?r=143

The branch is here:
http://fluent-nhibernate.googlecode.com/svn/branches/pb-rewrite

This shouldn't mean much for Fluent NHibernate users at the moment, as it is nowhere near being as functional as the trunk. However I would really like some feedback from the Fluent NHibernate devs. Does it look like it is worth pursuing further? Can you imagine us switching to it eventually? Did I miss Chad's point completely and am doing it all wrong? Comments and criticisms all welcome.

Thanks,

Paul Batum

[James Gregory]

Looks really good Paul. I haven't had the opportunity to have a deep dig, but from what I've read in the changelog and your blog post, I think this is definitely the direction we need to be heading. The separate model will help shield the fluent API from changes in the NHibernate XML, and just keeps the whole thing more solid.

I'm sure you've got quite a bit to do yet, but if and when the time comes I'll be willing to lend a hand (as I'm sure the other devs will be too).

[Andrew Stewart]

HI James

Ok I think I understand, basically you want to create a model that matches the nhibernate xml and then serialize that to the xml in 1 big hit. A very grand plan indeed.

Maybe I'm missing the point at the moment, but bear with me. As far as I can see this is our current situation, the fluent interface generates all the xml in the IMapping.Write function, mainly from a mixture of values that where stored in the various dictionaries on the object but occasionally using some lambda reflection magic.

In my brain the means we have a poor internal model in the many dictionaries, so if we replace these dictionaries with an improved class model and move the reflection magic to a more appropriate location. Then jobs done - I making it sound easier than it probably is. 

Whats more if we can maintain compatibility by not breaking the external fluent interface then we can proceed with out breaking AutoMapping or conventions. If we can keep the interface method for IMapping.Write to generate the xml, potentially this could be a small transition on a class by class basis rather than a full rewrite.

Hope this makes sense it's hard to explain this kind of stuff by email.

Andy

Disclaimer: I've not looked at the code, just read the changelog and the blog, so you may of done all this anyway.

--
=================
I-nnovate Software - Bespoke Software Development, uk wirral.
http://www.i-nnovate.net

[Paul Batum]

Andrew,

What you're suggesting does make sense. There are two reasons why I was less interested in that approach, one that I discussed today and one that I did not.

The first reason, is that I would like fluent nhibernate to support multiple fluent apis. For example: I want it to be practical for someone to build a fluent API that makes DDD easy, something like

class CustomerAggregate : Aggregate<Customer>
{
  public CustomerAggregate
  {
     Includes(c => c.Orders)
     HasValue(c => c.Address)
   }
}

If you look at the code base of my branch, you'll see that the current fluent api of HasMany, References, etc is in a seperate assembly. Decoupling the fluent api from the mapping model allows for more experimentation with fluent apis and I think this would be healthy.

The second reason is something that I did not discuss today, but have mentioned before: currently we have a problem when people want mappings that aren't supported, such as <any>. The only options avaliable to someone that wanted to use <any> is to write the file in xml or to check out our code and hack the support in. The approach of using the Hbm* classes means that if someone wants to use a feature that isn't supported yet, they can do so within fluent nhibernate. The Hbm graph is right there and open to manipulation. They might have to use the nasty API rather than the pretty API, but they don't have to break out and write xml. The other beneficial aspect of this is we have more chance of recieving useful patches. Once somebody goes to the trouble of writing the code that manipulates the Hbm graph to give you a <any>, they are actually very close to having a useful patch. The same isnt true if they break out completely and write their mapping in xml.

Thanks for your feedback

Paul Batum

[Jeremy D. Miller]

Paul,

If you haven't already, spend some time with Fowler's patterns for Internal DSL's at http://martinfowler.com/dslwip/.  He has quite a bit of writing that deals with this very subject.  What we want to do is have a separate "Semantic Model" that models the mapping, and just make the FI part write and configure the mapping model.  I definitely agree that things like auto mapping and conventions will work much more smoothly with this approach as opposed to writing to the Xml.  I am dubious about the HBM class structure though.  I think NHibernate itself needs a new Semantic Model.

At some point I think Fluent NHibernate needs to completely break away from generating the XML altogether and use different mechanisms.

Regards,

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Paul Batum <paul....@gmail.com>
To: fluent-n...@googlegroups.com
Sent: Tuesday, December 9, 2008 1:03:25 AM
Subject: [fluent-nhib] My attempt to rewrite fluent nhibernate

[Paul Batum]

Hi Jeremy,

I knew he was writing a book but have not spent any time with that resource. Thank you for the advice, I will take a look.

In regards to having a semantic model for fluent nhibernate , I thought that the classes you can find in the FluentNHibernate.MappingModel namespace of the core were the beginnings of that model. I will concede that they are not very rich at the moment, but I expect that will change once support for conventions and automapping is introduced. It is possible that I misunderstood though, so if you think I've missed the point completely, and those classes are NOT the beginnings of a semantic model, please say so!

I agree with you that NHibernate needs to shed its dependence on xml, but this seems like a very big problem. I have a thin glimmer of vain, unrealistic hope that this branch will grow to be successful enough that nhibernate proper will be open to adding support for configuration directly from our semantic model. Were that to happen we could rip out the underlying Hbm structure and say goodbye to xml. But until some very big changes occur on the nhibernate side of things, I see no alternative to generating xml. I also am not content just to sit and wait until these changes happen. I would rather try to make progress even if the solution does not seem ideal, and see where that takes us.

Thanks!

Paul Batum