Well the Chunk isn't an override, it doesn't override anything. It allows
you to configure the model separately, whether you choose to override
something defined elsewhere is your decision. The chunk allows you to
configure the model in separate "chunks", not in one fell-swoop.
The IMappingOverride on the other hand is an override, hence why it's in the
name.
On Tue, Feb 10, 2009 at 2:26 PM, Billy <wmccaffe...@gmail.com> wrote:
>
> Heh, I have to admit that was the one thing that I didn't like
> either. Technical aesthetics. ;)
>
> Why not a name which describes more what it's purpose is; e.g.,
> ConventionOverrideFor<>, AutoMapOverrideFor<> or something like that?
>
> Billy
>
>
> On Feb 10, 5:00 am, James Gregory <jagregory....@gmail.com> wrote:
> > ...and there's me thinking chunk was an amusing name ;)
> > ConfigPart, Configurer, Config, ConfigUnit, any ideas?
> >
> > On Tue, Feb 10, 2009 at 11:47 AM, Jimit <jimitndi...@gmail.com> wrote:
> >
> > > That's it. :)
> >
> > > On Feb 10, 11:19 am, James Gregory <jagregory....@gmail.com> wrote:
> > > > What's wrong with the chunk? naming?
> >
> > > > On Tue, Feb 10, 2009 at 10:49 AM, Jimit <jimitndi...@gmail.com>
> wrote:
> >
> > > > > +1 for the IMappingOverrides option. I ended up doing something
> pretty
> > > > > similar that works pretty well so far.:
> >
> > > > > public AutoPersistenceModel
> ApplyMappingOverridesFromAssembly<T>(this
> > > > > AutoPersistenceModel)
> > > > > {
> >
> > > > > IEnumerable<MethodInfo> mappingOverrides =
> > > > > from type in
> > > > > typeof(T).Assembly.GetTypes()
> > > > > where
> > > > > type.IsSubClassOf(typeof (IMappingOverride<>))
> > > > > from method in
> > > > > type.GetMethods()
> > > > > where
> > > > > method.DeclaringType == type
> > > > > &&
> > > > > method.ReturnType == typeof (void)
> > > > > &&
> > > > > method.GetParameters().Count() == 1 &&
> >
> > > > > method.GetParameters()[0].ParameterType.
> >
> > > > > GetGenericTypeDefinition() ==
> > > > > typeof
> > > > > (AutoMap<>)
> > > > > select method;
> > > > > mappingOverrides.ForEach(method =>
> > > > > {
> > > > > var entityType =
> > > > >
> method.GetParameters()
> > > > > [0].ParameterType.GetGenericArguments()[0];
> > > > > var autoMapType = typeof
> > > > > (AutoMap<>).MakeGenericType(new[] {entityType});
> > > > > var actionType = typeof
> > > > > (Action<>).MakeGenericType(new[] {autoMapType});
> > > > > var mappingAction = new[]
> > > > > {Delegate.CreateDelegate(actionType, method)};
> >
> > > > > InvocationHelper.InvokeGenericMethodWithDynamicTypeArguments(
> > > > > model,
> > > > > map =>
> > > > > map.ForTypesThatDeriveFrom<Object>(null),
> > > > > mappingAction,
> > > > > entityType);
> > > > > });
> > > > > return model;
> > > > > }
> >
> > > > > Not too crazy about the IAutoMappingConfigChunk though.
> >
> > > > > On Feb 10, 12:15 am, Billy <wmccaffe...@gmail.com> wrote:
> > > > > > 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 <jagregory....@gmail.com>
> 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-configchunkstuffhttp://
> > > > > gist.github.com/61097-IMappingOverride<T> stuff
> >
> > > > > > > What do you guys think?
> >
> > > > > > > On Mon, Feb 9, 2009 at 9:36 PM, Steven Harman <
> > > stevehar...@gmail.com>
> > > > > 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 <
> > > > > jagregory....@gmail.com>wrote:
> >
> > > > > > > >> One for each then, thanks guys! :)
> >
> > > > > > > >> On Mon, Feb 9, 2009 at 9:28 PM, Steven Harman <
> > > > > stevehar...@gmail.com>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 <
> wmccaffe...@gmail.com>
> > > > > 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 <jagregory....@gmail.com
> >
> > > 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 <
> > > wmccaffe...@gmail.com>
> > > > > 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
> >
> > ...
> >
> > 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 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
-~----------~----~----~----~------~----~------~--~---
