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
On Tue, Dec 9, 2008 at 8:52 PM, Andrew Stewart <[EMAIL PROTECTED]
> wrote:
> 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.
>
> On Tue, Dec 9, 2008 at 8:57 AM, James Gregory <[EMAIL PROTECTED]>wrote:
>
>> 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).
>>
>>
>> On Tue, Dec 9, 2008 at 7:03 AM, Paul Batum <[EMAIL PROTECTED]> wrote:
>>
>>> 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
>>> <http://groups.google.com/group/fluent-nhibernate/msg/57f151b4c047eab5?hl=en>completely
>>> and am doing it all wrong? Comments and criticisms all welcome.
>>>
>>> Thanks,
>>>
>>> Paul Batum
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> =================
> I-nnovate Software - Bespoke Software Development, uk wirral.
> http://www.i-nnovate.net
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibernate@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
