What is "narrowing proxy" warning?

[Darius Damalakas]

Hi,

I've just upgraded to NH 2.1.x branch, and i get these errors:

WARN NHibernate.Engine.StatefulPersistenceContext.ProxyWarnLog
[(null)] - Narrowing proxy to RisingStar.BLL.Model.Contact - this
operation breaks ==


I checked the code, and it says this:
"If the existing proxy is insufficiently "narrow" (derived),
instantiate a new proxy and overwrite the registration of the old one.
This breaks == and occurs only for "class" proxies rather than
interface" proxies" (StatefulPersistenceContext.cs: 680)

What does it mean "inssuficiently narrow ? Could someone provide an
example, when a proxy is not sufficiently narrow?

[Darius Damalakas]

I've found some nice documentation on this in Hibernate documentation.

http://docs.jboss.org/hibernate/stable/core/reference/en/html/performance.html#performance-fetching-proxies


What is interesting is that everything boils down to the fact that
"These problems are all due to fundamental limitations in Java's
single inheritance model". I guess the same applies to C#, since it
also supports only single inheritance.

They also propose a solution - instruct that proxies must be
constructed for interfaces, not for implementations. They give this
example:

<class name="CatImpl" proxy="Cat">
......
<subclass name="DomesticCatImpl" proxy="DomesticCat">
.....
</subclass>
</class>

[Fabio Maulo]

Yes, Darius... but every time I write a post talking about the usage of interfaces for entities (including only interfaces without classes or even only mappings without classes nor interfaces) somebody point me to Anemic Domain Model anti-pattern.

When somebody point me to an anti-pattern for sure I read which is the full description of the anti-pattern and, over all, I pay attention to the possible problems... after that I do what I need (pattern or anti-pattern).

2009/7/16 Darius Damalakas <darius.d...@gmail.com>

--
Fabio Maulo

[Tuna Toksoz]

I find interfaces useful in some cases. IMHO, a pattern might be an antipattern depending on the context.

Tuna Toksöz
Eternal sunshine of the open source mind.

http://devlicio.us/blogs/tuna_toksoz
http://tunatoksoz.com
http://twitter.com/tehlike

[Darius Damalakas]

This topic goes way beyond NHibernate, but ... :)

Our domain model i believe is strictly Anemic. We even impose the
requirement, that no business logic is there. Our domain classes are
only data carriers, decorated with Castle.ActiveRecord attributes to
convey the mapping for NH.

Now talking about interfaces, i think they have a strong argument
against putting logic into POCO (that is, for making anemic domain
model). The reason is what features your interfaces allow to introduce
into your application (easily, and without too much work). What i am
talking about is data auditing.

Yesterday we were studying how Hibernate.Envers is doing auditing, and
we found that for each domain class they create a second table, with
all the fields in original class, plus some fields for versioning,
such as Revision and Modification type (delete/insert/update).

Now the real question is not how we will put the auditing data into
those tables. This is easy done with interceptors. What is a question
for me is how you can present that historical data for the application
users! The problem is that who will write a mapping for the auditing
classes, which are mostly the same as your domain model.

To make long post-short, the answer is Interfaces! If you create two
interfaces - IClient, and IAuditInfo, then audit class is simply a
combination of these two interfaces, and our domain class can be a
normal IClient implementation. If we using the approach that Fabio
Maulo suggest, that is to generate implementations on the fly for the
interfaces, we solve the problem of who is going to make the mapping
for the auditing classes.

On 16 Lie, 23:37, Tuna Toksoz <tehl...@gmail.com> wrote:
> I find interfaces useful in some cases. IMHO, a pattern might be an
> antipattern depending on the context.
>
> Tuna Toksöz
> Eternal sunshine of the open source mind.
>

> http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitter.com/tehlike

>
> On Thu, Jul 16, 2009 at 4:53 PM, Fabio Maulo <fabioma...@gmail.com> wrote:
> > Yes, Darius... but every time I write a post talking about the usage of
> > interfaces for entities (including only interfaces without classes or even
> > only mappings without classes nor interfaces) somebody point me to Anemic
> > Domain Model anti-pattern.
> > When somebody point me to an anti-pattern for sure I read which is the full
> > description of the anti-pattern and, over all, I pay attention to the
> > possible problems... after that I do what I need (pattern or anti-pattern).
>

> > 2009/7/16 Darius Damalakas <darius.damala...@gmail.com>

>
> >> I've found some nice documentation on this in Hibernate documentation.
>

> >>http://docs.jboss.org/hibernate/stable/core/reference/en/html/perform...