ProxyGenerator: No Default

[Fabio Maulo]

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

[Tuna Toksöz]

If we don't have any default, does that mean that we don't have any proxy gens in the release package?

--
Tuna Toksöz

Typos included to enhance the readers attention!

[Fabio Maulo]

2008/11/7 Tuna Toksöz <teh...@gmail.com>

If we don't have any default, does that mean that we don't have any proxy gens in the release package?

We can have one or all even if in Contrib we have a specific prj about it.

No Default mean: each developer must choose what he want use.

Bye. 
Fabio Maulo

[Diego Jancic]

Fabio,
I guess it would be better for advanced users, because you make them read and learn and decide what is better for them.
But for newbies it will be harder to start, more thinks to understand, and so on...

I guess it would be better to keep a proxy gen for default based on performance tests and functionality, and most users will be happy forever.

Bye
Diego

[Fabio Maulo]

Hi Diego.

I will change configuration templates, docs, and a good exception message.

The newbie must know how configure a dialect and must know how configure a proxyFactoryFactory.

For who are not using IoC, probably, LinFu will be more than enough.

2008/11/7 Diego Jancic <jan...@gmail.com>

--
Fabio Maulo

[Jon Palmer]

If configuration is as simple as setting a configuration string (like dialect) that doesn’t sound so bad. However I think it’s important that you don’t have to download a separate package for you proxyGen of choice, some reasonable set of default choices should be included in the distribution so that NHibernate works ‘out of the box’

 

JP

[Bill Pierce]

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.

[Fabio Maulo]

IMO NHPG is and will be very useful prj for who are working with NH+Castle in medium-trust.

The name "ProxyFactories" or "ProxyGenerators" or "ByteCodeProviders" is not so fundamental.

What is really important for me is have a choice.

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.

When I work in NH I don't think about what I like or what I'm using for my customers; my mind is concentrated to understand what is good for NH and NH-users.

If you want I can change the name of the namespace from "ProxyGenerators" to "ProxyFactories" and maintain all prjs in trunk since, as Jon said, is important to deploy it with the Core.

Ok... open vote:

a) ProxyGenerators

b) ProxyFactories

c) ByteCodeProviders

2008/11/7 Bill Pierce <wcpi...@gmail.com>

--
Fabio Maulo

[Tuna Toksöz]

ProxyFactories would be my choice

 

But the sad thing is: NHibernate.ProxyFactories.xxxxDynamicProxy.ProxyFactoryFactory  :):):)

On Fri, Nov 7, 2008 at 7:13 PM, Fabio Maulo <fabio...@gmail.com> wrote:

ProxyFactories

[Fabio Maulo]

well.... we can make the "thing" more easy...

We are not sure which name is good ?

Skip that name:

NHibernate.xxxxDynamicProxy.ProxyFactoryFactory

No?

2008/11/7 Tuna Toksöz <teh...@gmail.com>

--
Fabio Maulo

[Jesse Napier]

Since there is a lot of discussion going on today about different proxy generator/ factory implementations I would like to mention a bug that I found when dynamic proxy dependency was removed from NHibernate. I added the bug to Jira but it has not been looked at yet.  I wanted to mention it today so that new implementations do not get built with the same bug that does not pass the test which I added to Jira.

 

http://jira.nhibernate.org/browse/NH-1549

 

Thanks,

Jesse

 

 

---

From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com] On Behalf Of Fabio Maulo
Sent: Friday, November 07, 2008 10:26 AM
To: nhibernate-...@googlegroups.com
Subject: [nhibernate-development] Re: ProxyGenerator: No Default

 

well.... we can make the "thing" more easy...

[Fabio Maulo]

patch welcome.

2008/11/7 Jesse Napier <jna...@gamefly.com>

--
Fabio Maulo

[Fabio Maulo]

Decision taken it will be:

NHibernate.ByteCode.Castle

NHibernate.ByteCode.LinFu

NHibernate.ByteCode.xyz

It is because the real responsibility to provide a ProxyFactoryFactory is of an implementation of IBytecodeProvider and we can maintain our specific feature IInjectableProxyFactoryFactory and the same architecture of Hibernate3.2.

2008/11/7 Fabio Maulo <fabio...@gmail.com>

--
Fabio Maulo

[hammett]

On Fri, Nov 7, 2008 at 9:13 AM, Fabio Maulo <fabio...@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.

--
Cheers,
hammett
http://hammett.castleproject.org/

[Fabio Maulo]

2008/11/10 hammett <ham...@gmail.com>

On Fri, Nov 7, 2008 at 9:13 AM, Fabio Maulo <fabio...@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.

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.

Bye.
Fabio Maulo

[hammett]

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

[Fabio Maulo]

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

--
Fabio Maulo

[Ramana-Sowmya Kumar]

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

 

[Fabio Maulo]

A far I know Ninject don't have owned DynamicProxy generator. If I well remember Ninject allow you to choose one (LinFu or Castle).

About default ProxyFactoryFactory (that is another "thing" than ProxyFactory) NH don't have a default. As the "dialect" is better if the user know what he want use.

More infos are available here:

http://nhforge.org/blogs/nhibernate/archive/2008/11/09/nh2-1-0-bytecode-providers.aspx

2008/11/12 Ramana-Sowmya Kumar <ramana...@gmail.com>

--
Fabio Maulo

[Henry Conceição]

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

[Fabio Maulo]

2008/11/12 Henry Conceição <henry.c...@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

[Fabio Maulo]

Ah Henry...

Remember that the wiki of NH-Forge is free and open. You can post there something about the ProxyFactoryFactory and reasons because each if better than other.

2008/11/12 Fabio Maulo <fabio...@gmail.com>

--
Fabio Maulo

[Henry Conceição]

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

[Tuna Toksöz]

The reason not to put dialect as a default is not that obvious but think it that way: MSSQL releases new versions every 3-4 years. SQL2000 didn't have paging for example, this is an important thing.

I have to agree on Henry's point, we should have default one in the release packages!

[Fabio Maulo]

2008/11/12 Henry Conceição <henry.c...@gmail.com>

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

Good point.

Please put your comment here

http://nhforge.org/blogs/nhibernate/archive/2008/11/09/nh2-1-0-bytecode-providers.aspx

and, if you want, add something here

http://nhforge.org/groups/nhusers/wiki/default.aspx

about Castle.DynamicProxy2 (2.0.3)

Only because NH-Forge is more visible than this dev-list.

 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!!!!"

So far we have the same questions about: "why I must declare all methods and properties of MY entities as 'virtual' ?"

Before make another comment about what happen for ProxyFactoryFactory not found please try it.

Thanks.
Fabio Maulo