I think that is the point that Hammet's was trying to explain. Your IoC framework has nothing related with the NHibernate's proxy generator. So if the rationale for the change it this, it's wrong or misleaded. An acceptable rationale is that the users should have the ability to choose/change a ProxyGenerator of NHibernate, base on him preferences and needs.
But as an user, I don't see any advantage in the proxygenerator becomes an _obrigatory_ config key. I've been using DynProxy for years, and I'm happy with it, and I'm don't want to change. I think that should be an default, and if someone want to change, fine, let him specify the new generator. My point is: less than 1% percent of the NHibernate user base will change it. There is no publics and trustable's benchmarks (remember, I'm talking about ProxyGenerators, not IoC containers). And worst, the great part of the user base, probably (I said probably), even doesn't know the implications of change the ProxyGenerator or the diff between PostSharp and DynamicProxy2. Btw, I think ByteCode generator isn't a good name or namespace pick. ByteCode is Java specific term, imho. IL Generator sounds more natural, for more. Just my two cents. Cheers, Henry Conceição On Wed, Nov 12, 2008 at 1:13 PM, Ramana-Sowmya Kumar <[EMAIL PROTECTED]> wrote: > Hi Fabio > I agree that the ability to switch ProxyFactory is is a good thing. If I am > already using NInject, I would probably switch from castle to Ninject. I > still think that NHibernate should have a default and ship with that. Most > NHusers don't use IOC/DI anyway and could care less which one is used in > NH. NH should use a one "default" (be it LinFu, Castle whatever). > Optionally, one could override the default and use other ProxyGenerator or > build your own. > Thanks > Ramana > > > On 11/11/08, Fabio Maulo <[EMAIL PROTECTED]> wrote: >> >> I like modeling using interfaces for entities too. >> If you know what is ProxyFactory you know that mean write the base class >> for all proxies in NH. >> An example of ProxyFactory implementation is available in one of the tests >> of NHibernate.ByteCode.Castle. >> That tests show how, who want write his ProxyFactory must know >> the underlining "Proxy generator" and who are writing proxies implementation >> using Spring or LinFu must have a choice to write his proxyFactory using >> what he want. >> >> I don't understand you disappoint. >> NH are leaving the user to choose RDBMS, ByteCode-provider, Transaction >> Factory, ConnectionProvider and so on... the DynProxy system is only one >> more "no-intrusion" of NH. >> >> If you have a "strong opinion" about why NH must have an hard reference to >> Castle.DynamicProxy I'm open to hear it. >> >> 2008/11/11 hammett <[EMAIL PROTECTED]> >>> >>> On Tue, Nov 11, 2008 at 4:33 AM, Fabio Maulo <[EMAIL PROTECTED]> >>> wrote: >>> > Probably; both are fruit. >>> > Who are using IoC, probably, are using AOP of the same FW; who are >>> > using AOP >>> > are using DynProxy. >>> > Now, who want can use the same DynProxy in NH (for example to inject >>> > the >>> > ProxyFactory) >>> > Some weeks ago Oren begin a branch to use NH with PostSharp; a complete >>> > separation from the DynProxy is needed. >>> > BTW to have more than one choice is a good thing; for that i'm using >>> > IoC. >>> > Thanks to leave here your opinion. >>> >>> >>> Not sure I follow. I might be using Spring or Windsor, they wont >>> interfere on how NH handles proxies. AOP will be limited to my >>> services, not domain classes. >>> The choice of what I'd like NH to use to create proxies (be it DP, >>> PostSharp or whatever) is orthogonal to my choice of framework stack. >>> >>> Anyway, I was just curious on the rationale - which seems broken. No >>> strong opinions. >>> >>> -- >>> Cheers, >>> hammett >>> http://hammett.castleproject.org/ >>> >> >> >> -- >> Fabio Maulo >> >
