> I want to clear up some confusion that appears to be my doing when I
> added the NHibernate.ProxyGenerators project to NH Contrib.  I didn't
> pick up on it fully until now so I apologize for writing this so
> late.  The Contrib project is a .Net Console application.  The purpose
> of this Console app is to generate an assembly that contains all
> INHibernateProxy classes needed by NHibernate to achieve lazy loading,
> etc.  The Console application is extensible enough to use any
> framework for generating this assembly.  Currently the only
> implementation is Castle.DynamicProxy.  The Contrib project is not
> currently meant to house different runtime implementations.  It is
> meant for housing different compile time assembly generators.  This
> was the purpose for the naming distinction of "Generator".

> I believe now that Fabio envisioned the Contrib project to house
> various proxy "Factory" implementations.  Breaking out the
> Castle.DynamicProxy implementation from the core project, adding a
> LinFu implementation, and adding others in the future.  I believe
> there should be another Contrib project called
> NHibernate.ProxyFactories where these items could live.  We could then
> revisit whether or not the existing ProxyGenerators project is still a
> valid Contrib project.

> On Nov 6, 7:56 pm, "Fabio Maulo" <fabioma...@gmail.com> wrote:
> > Hi friends.
> > I'm thinking to remove the optionality of proxyfactory.factory_class
> > property in the configuration, making it mandatory as the dialect.

> > This change is because we will have some more ProxyGenerators, so far
> hosted
> > in NH-Core, and I would like that the user choose which one he want use.
> > When SourceForge give me permission (arg!) I will commit the
> > new NHibernate.ProxyGenerators.LinFuDynamicProxy and, hopefully, a new
> one
> > next week.

> > The last release of LinFu.DynamicProxy pass all existing tests and I'm
> > thinking to use it for our tests (mean our default ProxyGenerator for
> > NH-Tests).

> > In the future I don't know which will be the location of the
> > others ProxyGenerators, may be NH-Contrib after the official release
> > of NHibernate.ProxyGenerators project.

> > Bye.
> > Fabio Maulo

> On Fri, Nov 7, 2008 at 9:13 AM, Fabio Maulo <fabioma...@gmail.com> wrote:
> > In various projects I'm using Castle but I know that there are a lot of
> > people using Spring with NH others that prefer Ninject and so on.

> How does using Spring or Ninject affect your choice of proxy
> generator? You're mixing apples and oranges.

> On Tue, Nov 11, 2008 at 4:33 AM, Fabio Maulo <fabioma...@gmail.com> 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/

> 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 <hamm...@gmail.com>

>> On Tue, Nov 11, 2008 at 4:33 AM, Fabio Maulo <fabioma...@gmail.com>
>> 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

> 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 choice? Castle's DynamicProxy2? Why? It's stable for a long time,
> had a lot of work spent in optimizations. It's second generation
> framework and it's seems to be the industry standard (for dynamic
> proxy generation).

> I wouldn't go with Post Sharp because, afaik, It requires a compile
> time tweaks, build hooks. And I don't like this kind approach, but can
> recognize that someday, in some situation It might by useful, so an
> extension point is nice.

> About the dialect: This is a good question. Why not to put it as
> default? In the last three years, I delivered only two projects that
> weren't backended by mssql.

> And btw, be ready to answer the same questions, over a million of
> times, no matter how well documented it will be:
> "HEELPP!!!!!! PROXY GENERATOR FACTORY NOT FOUND!!!!!" or  "URGENT!!!!!
> DEADLINE TOMORROW!!!! MY PROXIES AREN'T BEHAVING AS EXPECTED!!!!"

> Cheers,
> Henry Conceição

> On Wed, Nov 12, 2008 at 2:08 PM, Fabio Maulo <fabioma...@gmail.com> wrote:
> > 2008/11/12 Henry Conceição <henry.concei...@gmail.com>

> >> 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.

> > I would like to know which is your preference, for default
> > ProxyFactoryFactory, and reasons because you a choosing it, instead the
> others.
> > After that, I would like to know why we don't have a default for dialect
> since we know that, at least, 80% of users are using NH with
> > MsSQL.

> > Thanks.
> > Fabio Maulo

> My choice? Castle's DynamicProxy2? Why? It's stable for a long time,
> had a lot of work spent in optimizations. It's second generation
> framework and it's seems to be the industry standard (for dynamic
> proxy generation).