Re: [Springframework-developer] BeanWrapperImpl abstraction

[<jue...@we...>]

OK, I see. But I don't see a strong need to factor a base class out, =
actually. Rather, I see a need to make some of the currently private =
methods in BeanWrapperImpl protected, to allow for easier subclassing - =
in particular:

- getPropertyValue(String propertyName, String actualName, String key)
- setPropertyValue(String propertyName, String actualName, String key, =
Object value)

Can you try to figure out the exact set of methods that you need =
protected rather than private? We can then still decide to factor out a =
base class; but for a start, it would be good enough to allow for =
subclassing BeanWrapperImpl itself.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen
Sent: Tuesday, June 08, 2004 2:19 PM
To: spr...@li...
Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction


> I wouldn't mind such a refactoring. However, I don't see the clear
> distinction between the new base class and BeanWrapperImpl: If the
base
> class contains everything including bean introspection, what exactly
is
> BeanWrapperImpl supposed to add - respectively, what does your own
> subclass do differently?

To allow for partial results to be returned from (Hibernate) queries but
still letting the clients believe it's a concrete object, my own
BeanWrapper is backed by a PropertyValues object rather than the real
object. A call to getWrappedInstance() returns a Proxy, proxying to
BeanWrapper to retrieve the values.

This allows me to without changing anything to the view (the view can
still use the databinder and the actual wrapped instance as internally
that uses the BeanWrapper backed by the PropertyValues) switch from
full-objects to partial objects being returned to the view or fat
client.

Reason for all this: complex domain model with huge objects (healthcare
and the like) with stringent security requirements (certain parts of
objects just cannot be transferred over the wire for example). Both the
security requirements are met as well as the performance troubles
(heavily interlinked domain model, where clients hardly ever need to
view more than 5% of all data available). The latter could probably be
solved by using the open session in view stuff, but it's problematic
with fat and remote clients.

> I assume that your own subclass wouldn't implement the BeanWrapper
> interface in the first place, because it has its own API way. I just
> wonder what it looks like then :-)
Yes it does implement BeanWrapper ;-). It has the exact same
functionality (you cannot modify properties with it, just read them).

> I doubt that there will ever be an alternative implementation of the
> BeanWrapper interface itself. It still makes sense to decouple
interface
> and implementation here, if just for testability. BeanWrapperImpl
already
> is a quite complex piece that you shouldn't necessarily work with
> directly.
It's a rare use case, but actually makes sense (to me ;-). Same
functionality, different wrapped object.

> If the changes don't affect the public BeanWrapper API, I wouldn't
mind
> including them in 1.0.3 - provided that we're just talking about a
> refactoring that does not modify existing functionality.
In my use case the only thing that changes is the wrapped instance (more
specifically, the data container actually holding the data of the
(proxied) interface being wrapped). Basically I would stick with the
current API of the BeanWrapper and implement the AbstractBeanWrapper as
a somewhat strategy-like class, where the current BeanWrapperImpl just
has to override get/setPropertyValue(propertyName, actualName, key)
method, currently delegating to the read/writeMethods of the object
being wrapped (there is where I need to make changes).

alef



-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer