As James mentioned, he and I have already discussed the topic of new
conventions + semantic model. I really don't think its going to be a
problem. Obviously, the inner machinery that makes James' conventions work
will change when we move to the semantic model, but our users will be
isolated from this.
On Thu, Mar 5, 2009 at 3:32 AM, James <james.freiwi...@gmail.com> wrote:
>
> Sounds excellent.
>
> On Mar 4, 8:10 am, James Gregory <jagregory....@gmail.com> wrote:
> > Guys,
> >
> > This email is a heads up, with an opportunity to provide feedback before
> I
> > commit these changes to trunk. I want to make it clear that I'm not
> bashing
> > the work of the developers before myself who wrote the original
> conventions
> > code. I mean no disrespect, it's just not my idea of where it should
> > proceed.
> >
> > Our current implementation of conventions is pretty unmaintainable, it's
> > merely a large class with several lambda functions that get called at
> > various stages in the mapping generation. Our mapping generation code has
> > logic for the conventions strewn about, and the convention functions
> > themselves are pretty awkward for anything other than really basic things
> > (once logic starts coming in, then the inline lambdas break down).
> There's
> > also no graceful degredation for support, we either support a convention
> or
> > we don't, there's very little room for people to work around missing
> > features, which is putting a lot of strain on future development.
> Finally,
> > when you're overriding a lot of conventions, your convention code can
> > quickly become large and cumbersome - there's no SoC.
> >
> > Those are my reasons for what I've been working on - a complete rewrite
> of
> > the conventions code.
> >
> > So how has it changed? The Conventions class has gone, for starters;
> which
> > means the inline overriding of conventions is gone too. Instead what you
> > have is a series of interfaces of varying degrees of granularity; any
> > classes implementing any of the interfaces will be automagically hooked
> into
> > FNHs generation cycle. What this equates to is you'll have a
> > folder/namespace dedicated to convention overrides, each class in there
> > making an alteration to the conventions when it's called. Because the
> > conventions are defined as interfaces, that means you can have a single
> > class handle multiple conventions of the same kind too.
> >
> > An example or two:
> >
> > public class TableNameConvention : IClassConvention
> > {
> > public bool Accept(IClassMap classMap)
> > {
> > return classMap.EntityType.IsSubclassOf(typeof(Customer));
> > }
> >
> > public void Apply(IClassMap classMap)
> > {
> > classMap.WithTable("Customer_" + classMap.EntityType.Name);
> > }
> >
> > }
> >
> > public class ColumnNameConvention : IPropertyConvention, IIdConvention
> > {
> > public bool Accept(IProperty property)
> > {
> > return true;
> > }
> >
> > public bool Accept(IIdentityPart id)
> > {
> > return true;
> > }
> >
> > public void Apply(IProperty property)
> > {
> > var column = GetColumnName(property.Property);
> >
> > property.ColumnName(column);
> > }
> >
> > public void Apply(IIdentityPart id)
> > {
> > var column = GetColumnName(id.Property);
> >
> > id.ColumnName(column);
> > }
> >
> > private string GetColumnName(PropertyInfo prop)
> > {
> > return prop.Name.ToLower();
> > }
> >
> > }
> >
> > I'm very aware that these conventions are more verbose than our existing
> > ones, but the power and SoC is uncomparable.
> >
> > The setup has now been reduced to:
> >
> > WithConventions(conventions =>
> > conventions
> > .Add<TableNameConvention>()
> > .Add<ColumnNameConvention>());
> >
> > or simply:
> >
> > WithConventions(conventions =>
> > conventions.AddFromAssemblyOf<ColumnNameConvention>());
> >
> > Which could actually be changed to implicitly find any conventions in the
> > same assembly as your mappings, but that's another discussion.
> >
> > The interfaces you're provided with currently are:
> >
> > - IAssemblyConvention - Applied to an IEnumerable of IClassMap from
> each
> > assembly
> > - IClassConvention - Applied to each IClassMap
> > - IMappingPartConvention - Applied to every mapping part in a
> IClassMap
> > - IPropertyConvention - Applied to Map/Property's
> > - IIdConvention - Ids
> > - IVersionConvention - Versions
> > - IComponentConvention & IDynamicComponentConvention - Components
> > - IRelationshipConvention - Applied to all relationships
> > - IHasManyConvention, IHasManyToManyConvention, IHasOneConvention,
> > IReferenceConvention
> > - Applied to each relationship
> > - IUserTypeConvention & UserTypeConvention base - For use with
> IUserTypes
> > - IJoinConvention - Applied to joined tables
> > - AttributePropertyConvention - Applied to properties with attributes
> >
> > As you can see, there are a fair few options available. If we add a new
> > feature but forget to provide an interface for a convention, there's
> always
> > the level above instead. If IPropertyConvention didn't exist for example,
> > you could easily just implement IMappingPartConvention and write the
> Accept
> > method to only accept properties.
> >
> > I suppose I'm asking if anyone has any major objections to these changes?
> > Are you ok with losing the simplicity of overriding one or two
> conventions
> > inline, for the net gain of more power?
> >
> > James
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
