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 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 <stevehar...@gmail.com> 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 < >> andrewnstew...@gmail.com >> > > >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 <jagregory....@gmail.com> >> 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 <wmccaffe...@gmail.com> >> 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 <jimitndi...@gmail.com> 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 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 -~----------~----~----~----~------~----~------~--~---
