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
