Andrew: Paul and I have already spoke about this stuff and his branch, don't
worry about it. I'm not working on anything without first considering the
rewrite. As far as I'm concerned, development on trunk is going to slow down
and I'm going to commit some time to the semantic model rewrite; then we'll
do some form of disconnected merge and either push the SM into trunk, or
push the changes from trunk into the SM branch.
On Wed, Mar 4, 2009 at 2:08 PM, Andrew Stewart <andrewnstew...@gmail.com>wrote:
> Hi James
> Generally I agree that a rewrite of conventions needed to be done, you
> could really see that class was getting crowded and ugly. I'd of probably
> implemented it very similar to your way, however can any of this be
> achieved:
>
> - Some form of backwards compatibility layer for previous
> versions(maybe through extension methods or something)
> - Your approach is different to Paul's in the semantic layer these
> should probably be aligned together.
>
> However I'm going to vocalise something I'm very worried about, there seems
> to be 2 distinct development branches going on Paul's semantic rewrite
> and James piecemeal rewrite of sections of the trunk. I'm very concerned
> that these two branches will move too far apart, and that something has to
> happen to bring these together sooner rather than later. Otherwise I
> can foresee a day when it becomes easier to force a semantic model under
> James branch and we remove the original rewrite effort, and I don't like
> effort being wasted.
>
> I'd really like to hear what other people think about this.
>
> Cheers
>
> Andy
>
> On Wed, Mar 4, 2009 at 1:10 PM, 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
>>
>>
>>
>
>
> --
> =================
> I-nnovate Software - Bespoke Software Development, uk wirral.
> http://www.i-nnovate.net
>
> Easy Project Managment Online
> http://www.task-mate.com
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
