...and it's committed! *Hides from the angry mob of devs with broken builds* The wiki has been updated with the new syntax, as well as with some dedicated pages to conventions.
- Conventions <http://wiki.fluentnhibernate.org/show/Conventions> - Convention Interfaces<http://wiki.fluentnhibernate.org/show/ConventionsInterfaces> - Convention Shortcuts<http://wiki.fluentnhibernate.org/show/ConventionsShortcuts> - Converting to new style conventions<http://wiki.fluentnhibernate.org/show/ConvertingToNewStyleConventions> - Conventions behind-the-scenes<http://wiki.fluentnhibernate.org/show/ConventionsCode> On Wed, Mar 4, 2009 at 9:06 PM, Paul Batum <paul.ba...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
