That strategy works for me.

Thank you for being accommodating a viable approach to organizing
overrides.

Billy


On Feb 9, 4:37 pm, James Gregory <[email protected]> wrote:
> Well, I'm torn.
> I've just knocked together a prototype for what is essentially Billy's
> design, reworked a bit.
> I've created an IAutoMappingConfigChunk, which has an
> Configure(AutoPersistenceModel model) method. You add chunks to an APM, each
> one gets executed before the mappings are compiled.
>
> Leading on from that, I've created an IMappingOverride<T> interface, which
> has a single method of Override(AutoMap<T> mapping); this interface allows
> you to have the simplicity of class-per-override as the inheritance
> strategy, but without the nasty inheritance.
>
> IMappingOverride's are added using a custom IAutoMappingConfigChunk that
> takes an assembly and finds any types that derive from IMappingOverride. So
> i'm actually dogfooding the config stuff.
>
> http://gist.github.com/61092- config chunk stuffhttp://gist.github.com/61097- 
> IMappingOverride<T> stuff
>
> What do you guys think?
>
> On Mon, Feb 9, 2009 at 9:36 PM, Steven Harman <[email protected]> wrote:
> > Just doing my part to keep everyone thoroughly confused and confounded! :)
>
> > //----  90% of being smart is knowing what you're dumb at  ----//
> >http://stevenharman.net/
>
> > On Mon, Feb 9, 2009 at 4:34 PM, James Gregory 
> > <[email protected]>wrote:
>
> >> One for each then, thanks guys! :)
>
> >> On Mon, Feb 9, 2009 at 9:28 PM, Steven Harman <[email protected]>wrote:
>
> >>> Seeing this new way, I think I'd much prefer it to using inheritance.
> >>> I've really started to realize that inheritance is rarely the optimal
> >>> solution to a problem - often its simply the one we are most comfy with, 
> >>> and
> >>> so we naturally go there first.
>
> >>> So, I guess what I'm saying is... I'd rather see the extension method
> >>> way, as it adds a nice point of extension, while allowing us to leverage
> >>> composition to build really dynamic and granular mapping overrides. Or at
> >>> least, that's my gut reaction.
>
> >>> Thanks all,
> >>> -steve
>
> >>> //----  90% of being smart is knowing what you're dumb at  ----//
> >>>http://stevenharman.net/
>
> >>> On Mon, Feb 9, 2009 at 3:27 PM, Billy <[email protected]> wrote:
>
> >>>> James,
>
> >>>> Thank you for my input on the matter; albeit, I'd like it to be
> >>>> perfectly known that I'm still getting my feet wet with Fluent
> >>>> NHibernate and have a lot to learn on the subject.  Personally, I like
> >>>> the ability to inherit from AutoMap as it makes the behavior more
> >>>> interchangeable with ClassMap behavior.  It also makes the mapping
> >>>> identical in nature to that of ClassMap without having to introduce
> >>>> lambdas, which I see as complicating the matter, if only slightly.
> >>>> Finally, it makes it easier to use inheritance to create a grouping of
> >>>> overridden mappings.  For instance, suppose you want an
> >>>> AuditableAutoMap<> base class which inherits from AutoMap<> and
> >>>> overrides a number of conventions for any entity that is IAuditable.
> >>>> You could than have a concrete MyEntityMapClass which inherits from
> >>>> AuditableAutoMap<>, one for each IAuditable entity.  This would allow
> >>>> you to create an "override group" if you will.
>
> >>>> With that said, there are other approaches that could be taken to
> >>>> simulate on override grouping via encapsulation rather than via
> >>>> inheritance.  But it's nice to have the inheritance option, if only
> >>>> for organization and consistency with ClassMap. :D  When it comes down
> >>>> to it, there are decisions that must be made for the integrity of the
> >>>> design; if you feel that avoiding AutoMap inheritance is in the best
> >>>> interest of the overall design of Fluent NHibernate, then I'm very
> >>>> supportive of that decision as well.
>
> >>>> Thanks for all your great work on Fluent NHibernate...it's been a big
> >>>> hit within S#arp Architecture.
>
> >>>> Billy McCafferty
>
> >>>> On Feb 9, 1:07 pm, James Gregory <[email protected]> wrote:
> >>>> > I think what I've been saying may have been interpreted as being more
> >>>> > negative or hostile than I intended it to be. My basic point was,
> >>>> there
> >>>> > isn't a bug because you aren't using a "feature" of FNH.
> >>>> > I'm happy for this to become a proper supported way of overriding
> >>>> > automappings, but for me to be expected to support it I have to
> >>>> actually
> >>>> > write coverage for it. Until I do that, it's unofficial.
>
> >>>> > As for my stance on actually using it, as long as it's explained that
> >>>> they
> >>>> > are overrides (and as Steve said, with a decent naming convention)
> >>>> there's
> >>>> > nothing wrong with inheriting from AutoMap<T>. I'm all for SoC.
>
> >>>> > Billy: do you prefer your new way of writing the overrides, or would
> >>>> you
> >>>> > prefer to just inherit from AutoMap? Is this new way just to avoid the
> >>>> bug?
>
> >>>> > What I'm saying is: say the word and I'll make this an official
> >>>> feature;
> >>>> > then I won't moan about not supporting an unofficial feature.
>
> >>>> > On Mon, Feb 9, 2009 at 7:29 PM, Billy <[email protected]> wrote:
>
> >>>> > > Here's the final approach that I took to organize my overrides:
>
> >>>> > > 1) Add an override interface to your application as follows:
>
> >>>> > > using FluentNHibernate.AutoMap;
>
> >>>> > > namespace SharpArch.Data.NHibernate.FluentNHibernate
> >>>> > > {
> >>>> > >    /// <summary>
> >>>> > >    /// Used by <see cref="AutoPersistenceModelExtensions" /> to add
> >>>> > > auto mapping overrides
> >>>> > >    /// to <see cref="AutoPersistenceModel" />
> >>>> > >    /// </summary>
> >>>> > >    public interface IAutoPeristenceModelConventionOverride
> >>>> > >    {
> >>>> > >        AutoPersistenceModel Override(AutoPersistenceModel model);
> >>>> > >    }
> >>>> > > }
>
> >>>> > > 2) Create an extension method, as follows, to look for every class
> >>>> > > which implements IAutoPeristenceModelConventionOverride, in a
> >>>> > > particular assembly, and apply the override to AutoPersistenceModel:
>
> >>>> > > using FluentNHibernate.AutoMap;
> >>>> > > using System.Reflection;
> >>>> > > using System;
> >>>> > > using SharpArch.Core;
>
> >>>> > > namespace SharpArch.Data.NHibernate.FluentNHibernate
> >>>> > > {
> >>>> > >    /// <summary>
> >>>> > >    /// Provides a means to override <see cref="AutoPersistenceModel"
> >>>> /
> >>>> > > > conventions with classes
> >>>> > >    /// that implement <see
> >>>> > > cref="IAutoPeristenceModelConventionOverride" />.
> >>>> > >    /// </summary>
> >>>> > >    public static class AutoPersistenceModelExtensions
> >>>> > >    {
> >>>> > >        public static AutoPersistenceModel
> >>>> > > MapConventionOverridesFromAssemblyOf<TOverride>(
> >>>> > >            this AutoPersistenceModel autoPersistenceModel) where
> >>>> > > TOverride : IAutoPeristenceModelConventionOverride {
>
> >>>> > >            Assembly assemblyToPullConventionOverridesFrom = typeof
> >>>> > > (TOverride).Assembly;
>
> >>>> > >            foreach (Type type in
> >>>> > > assemblyToPullConventionOverridesFrom.GetTypes()) {
> >>>> > >                if (typeof
> >>>> > > (IAutoPeristenceModelConventionOverride).IsAssignableFrom(type)) {
> >>>> > >                    IAutoPeristenceModelConventionOverride instance =
> >>>> > >                        Activator.CreateInstance(type) as
> >>>> > > IAutoPeristenceModelConventionOverride;
>
> >>>> > >                    if (instance != null)
> >>>> > >                        instance.Override(autoPersistenceModel);
> >>>> > >                }
> >>>> > >            }
>
> >>>> > >            return autoPersistenceModel;
> >>>> > >        }
> >>>> > >    }
> >>>> > > }
>
> >>>> > > 3) Create a class for each entity that requires a convention
> >>>> override;
> >>>> > > for example:
>
> >>>> > > using FluentNHibernate.AutoMap;
> >>>> > > using Northwind.Core;
> >>>> > > using SharpArch.Data.NHibernate.FluentNHibernate;
>
> >>>> > > namespace Northwind.Data.NHibernateMappings
> >>>> > > {
> >>>> > >    public class CustomerMap : IAutoPeristenceModelConventionOverride
> >>>> > >    {
> >>>> > >        public AutoPersistenceModel Override(AutoPersistenceModel
> >>>> > > model) {
> >>>> > >            return model.ForTypesThatDeriveFrom<Customer>(map => {
> >>>> > >                map.SetAttribute("lazy", "false");
> >>>> > >            });
> >>>> > >        }
> >>>> > >    }
> >>>> > > }
>
> >>>> > > 4) Include a call to the extension method when setting up the
> >>>> > > AutoPersistenceModel; e.g.,
>
> >>>> > > AutoPersistenceModel mappings = AutoPersistenceModel
> >>>> > >    .MapEntitiesFromAssemblyOf<Customer>()
> >>>> > >    ...
> >>>> > >    .WithConvention(GetConventions)
> >>>> > >    .MapConventionOverridesFromAssemblyOf<CustomerMap>();
>
> >>>> > > I'll be including this approach in the next release of S#arp
> >>>> > > Architecture which leverages Fluent NHibernate.  Hope this helps!
>
> >>>> > > Billy McCafferty
>
> >>>> > > On Feb 9, 9:03 am, Steven Harman <[email protected]> wrote:
> >>>> > > > Being one of the folks currently using the AutoPersistenceModel in
> >>>> an
> >>>> > > > unconventional (or rather, just unexpected) manner, I suppose I
> >>>> should
> >>>> > > speak
> >>>> > > > up in favor of allowing, and suggesting, that class-specific
> >>>> convention
> >>>> > > > overrides be split out into their own auto mappings files. I'm on
> >>>> board
> >>>> > > > w/Andy - this approach keeps things more granular, better
> >>>> seperated, and
> >>>> > > > easier to grok when you have a large number of mappings.
>
> >>>> > > > That said, I also see James concern that it might not be obvious
> >>>> that
> >>>> > > these
> >>>> > > > small one-off maps are actually overriding some other auto
> >>>> mapping, setup
> >>>> > > > elsewhere. However, I think some smart naming conventions,
> >>>> namespacing,
> >>>> > > and
> >>>> > > > a little bit of education could go a long way toward
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Fluent NHibernate" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to