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 eliminating >>> that >>> > > > concern. But then, that's just my opinion. >>> > >>> > > > Perhaps talking about the various ways folks are using FNH mappings >>> (both >>> > > > auto and manual), and the lessons we're learning, would be a good >>> topic >>> > > for >>> > > > a VAN Meeting? >>> > >>> > > > -steve >>> > >>> > > > //---- 90% of being smart is knowing what you're dumb at ----// >>> > >http://stevenharman.net/ >>> > >>> > > > On Mon, Feb 9, 2009 at 9:44 AM, AndyStewart < >>> [email protected] >>> > > >wrote: >>> > >>> > > > > Hi James >>> > >>> > > > > I've not read the whole thread, so forgive me if I'm going in the >>> > > > > wrong direction. However let me shed some light on this, >>> > > > > looks like some users of the library are inheriting from AutoMap >>> and >>> > > > > using the model.addMappingsFromAssembly( ); method. >>> > > > > This is in-fact the very first way I wrote automappings, until >>> Chad >>> > > > > showed me the light to the fluent method. However if >>> > > > > your doing alot of custom mappins then loading in via seperate >>> classes >>> > > > > is a lot cleaner than the 80 lins of fluent code >>> > > > > I have in one of my projects (yuk). >>> > >>> > > > > Hope you this puts you in the picture as how this has come about. >>> > >>> > > > > Andy >>> > >>> > > > > On Feb 9, 10:33 am, James Gregory <[email protected]> >>> wrote: >>> > > > > > Billy, it's important to note that I never said you shouldn't >>> be >>> > > deriving >>> > > > > > from AutoMap<T>. If that works for you (or did...) then great. >>> My >>> > > point >>> > > > > is >>> > > > > > that this style of modeling has evolved without my knowledge, >>> which >>> > > is >>> > > > > > interesting and concerning at the same time; if it's a good >>> thing >>> > > then I >>> > > > > > have no issue with it, but I can't be seen to endorse it >>> without >>> > > > > > understanding the implications of it's use beforehand. >>> > > > > > For starters, we have no tests covering this code; which leads >>> us to >>> > > > > > situations like this where I manage to break it for people >>> without >>> > > ever >>> > > > > > knowing. We have no examples promoting this style (unless >>> somebody's >>> > > > > written >>> > > > > > some I wasn't aware of), and as a result we have no way of >>> supporting >>> > > > > this >>> > > > > > from a guidance perspective. >>> > >>> > > > > > My final disagreement with this is that I don't actually like >>> the way >>> > > it >>> > > > > > feels. It looks like a ClassMap, smells like a ClassMap, but is >>> an >>> > > > > AutoMap. >>> > > > > > You look at it and, unless you already know that it's an >>> AutoMap, >>> > > think >>> > > > > > "where are all the other mappings?" However, that could just be >>> me >>> > > > > because >>> > > > > > I'd not used it in this manner. >>> > >>> > > > > > All that being said, I can definitely see the merit in >>> separating the >>> > > > > > overrides into their own classes. People obviously like doing >>> > > overrides >>> > > > > in >>> > > > > > the manner that #arch does them, so presuming I can get the >>> code >>> > > under >>> > > > > test >>> > > > > > (and fix the bug), I have no issue with people proceeding. >>> > >>> > > > > > I've got some time tomorrow working on FNH, so I'll take a look >>> at >>> > > this >>> > > > > > then. >>> > >>> > > > > > On Mon, Feb 9, 2009 at 3:16 AM, Billy <[email protected]> >>> wrote: >>> > >>> > > > > > > I was also inheriting from AutoMap and ran into the same >>> exception >>> > > > > > > with recent updates. The workaround that I've put in place >>> for >>> > > this >>> > > > > > > issue for keeping overrides well organized is described at >>> > >>> > >http://groups.google.com/group/sharp-architecture/msg/c74d493fc74ed98 >>> . >>> > > > > .. >>> > > > > > > . >>> > > > > > > Although it's within the context of S#arp Architecture, it >>> could be >>> > > > > > > reused in any project. >>> > >>> > > > > > > Billy McCafferty >>> > >>> > > > > > > On Feb 3, 12:13 pm, Jimit <[email protected]> wrote: >>> > > > > > > > The method MergeWithAutoMapsFromAssembly<T>() seemed to >>> suggest >>> > > the >>> > > > > > > > style I used - that is, subclassing AutoMap<T> in an >>> assembly. It >>> > > did >>> > > > > > > > discover my automaps fine, but then failed with the error >>> > > described. >>> > > > > > > > My domain has some very deep hierarchies and the fluent >>> > > configuration >>> > > > > > > > (using ForTypesThatDeriveFrom<T>) was getting rather wordy >>> so I >>> > > > > > > > seperated them into individual subclasses of AutoMap<T> and >>> > > merged >>> > > > > > > > them into my AutoPersistenceModel using >>> > > > > > > > MergeWithAutoMapsFromAssembly<T>(). It seemed to work fine, >>> until >>> > > it >>> > > > > > > > didn't. :) I think subclassing AutoMap<T> should be >>> supported, >>> > > if >>> > > > > > > > nothing else than for consistency with ClassMap<T> for >>> > > non-automapped >>> > > > > > > > entities. >>> > >>> > > > > > > > Speaking of ForTypesThatDeriveFrom<T>, I think a >>> non-generic >>> > > overload >>> > > > > > > > might come in handy. One use case (that's got me stumped at >>> the >>> > > > > moment >>> > > > > > > > - having to use reflection) is setting conventions for the >>> open >>> > > form >>> > > > > > > > of a generic base type, e.g EntityBase<,>. In my particular >>> case, >>> > > I >>> > > > > > > > want to ignore certain properties in >>> EntityBase<TEntity,TId> but >>> > > > > don't >>> > > > > > > > want to have to tell the Automapper to ignore >>> > >>> > ... >>> > >>> > 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 -~----------~----~----~----~------~----~------~--~---
