It's official, I've implemented the generic configuration overrides (now
called IAutoMappingAlteration instead of Chunk), and the more specific
IMappingOverride<T>.
You can read about both on the wiki,
overrides<http://wiki.fluentnhibernate.org/show/AutoMappingOverrides>
and
configuration
alterations<http://wiki.fluentnhibernate.org/show/AutoMappingConfigurationAlterations>
.
On Tue, Feb 10, 2009 at 2:33 PM, James Gregory <jagregory....@gmail.com>wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
