It's definitely going to be nice to do the one-offs as something like:
Customize(Action<SemanticModel>)
instead of having to translate everything to the Xml
Jeremy D. Miller
The Shade Tree Developer
jeremydmil...@yahoo.com
________________________________
From: Chad Myers <c...@chadmyers.com>
To: fluent-nhibernate@googlegroups.com
Sent: Monday, January 12, 2009 1:38:45 PM
Subject: [fluent-nhib] Re: Rethinking Fluent NHibernate
We're mostly there, we have the starts of it, but AutoMap was build on top of
the Fluent API which has hampered it.
First, we need the semantic model. Paul Batum said he'd have this done by the
end of the week ;) j/k. We've kicked around ideas, this just needs a champion
to get the ball rolling.
Second, we get really serious about conventions. To the maximum extent
possible, all decisions and opinions become conventional.
Third, we'd need to take the existing automapping discovery code and use it and
possibly enhance it wherever it needs enhancement
Fourth, we expose the config directly and/or have an internal DSL for making
the one-off overrides and/or "more complex conventions" that depend on multiple
conditions being met for them to be applied, etc
-c
________________________________
From: fluent-nhibernate@googlegroups.com on behalf of Chad Myers
Sent: Mon 1/12/2009 1:36 PM
To: fluent-nhibernate@googlegroups.com
Subject: [fluent-nhib] Rethinking Fluent NHibernate
[Credit to Aaron Jensen for giving some great feedback and sending me down this
thought path, and numerous others who have complained about lack of
private/protected member support and for committers/contributors who've been
kicking around ideas and forging ahead with new ideas]
What if we took the convention stuff all the way to 11?
What if you could point FNH at your assembl(y|ies) and give it some criteria
(i.e. everything in namespace FOO, that derives from type BaseEntity, etc) and
it would discover all your entities that need mapped?
What if FNH would discover all the public properties and public/private fields
and could make reasonable guesses about how those should be mapped?
What if you could guide it conventionally to figure out how to map the tricky
parts?
Lasty, for very complex things, you could dip down to specifics.
I'm imaginging something like:
Dear Fluent NHibernate:
Please discover all my entities which are located in my "Core" assembly, in all
namespaces under the namespace ending with "Domain", and which derive from my
BaseEntity class.
You should know:
* All my entities have an "Id" property and should be mapped using the hi/lo +
guid.comb generators
* All my table names are the pluralized form of the entities names preceeded
with "t_"
* All my foreign key names start with "fk_"
* All my many-to-many join tables have the format "mtm_A_B" where A and B are
the pluralized form of the entity names
* (etc, etc, etc)
Also, if you come across an apparent relationship between Contact and Site, map
it as a OTM to an intermediate table (using entity ContactSiteRole) and then an
MTO to the other side (blah blah blah)
If you come across a relationship involving EntityA and EntityB, map it like
this...
By the way, I'd like you to make all OTM's "Cascade All" except for
relationships involving EntityF and EntityQ.
(and so forth)
-c
--~--~---------~--~----~------------~-------~--~----~
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
fluent-nhibernate+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
