Value Objects (Big, Small, Medium)
What is the correct usage of a value object in the following example:
I have an entity bean that encapsulates a business, and the bean has methods similar to getName(), getAddress(), etc. Lets say for example we have 75 accessors and 75 mutators for that bean.
I then use a session facade to provide access to the entity. The session facade will not provide the LocalObject nor the RemoteObject to the client. The session facade will create value objects to encapsulate the data. This will in effect make Remote entity references worthless.
So, in continuing the example, for my particular jsp, I only need name and address for a list. I find it a waste of memory to produce a value object with 75 fields to maintain when I only need 2.
Does this warrant a lightwight value object, or a full object with most instance variable referencing null? I could also place a LocalObject or RemoteObject reference as the only field in the ValueObject and the 75 fields will access that directly, which I assume will be lazily loaded at runtime, making the value object low in memory.
I am at a bind here, and appreciate your help.
Thanks,
Dan Hinojosa
I use objects that I call views. Each view will contain only the data that the page will need. I create the view with my facade which is called from my servlet controller. I put the view into the session and redirect to the jsp. All dynamic data for the jsp is contained in the view. Since I architect my apps for any type of client I have general views, html views, etc.
JSP1-->Servlet1--getHtmlView()->Session Facade/Web Adapter-getClientView()-> EJBs
My html views are simple...
public class DeptView implements ClientView {
public String name = "";
public String number = "";
}
The jsp would get the view from the session upon load.
t3chi3
Actually I used that strategy before but ended making so many "View Objects" that the code was hard to manage.
I came up with a solution three days a ago. I am enjoying this very much. I have a generic getData(int flag) method on my EntityBean.
The flag will determine what gets placed on to an all in one ValueObject.
In my Local and Remote interface I have finals like
Business.NAME = 0;
Business.ADDRESS = 1;
Business.CITY = 2;
and so forth so that I am getting a value object with my own construction so that I don't have to keep creating objects. : )
We'll see how good this goes for a while.
danno
What is the object being returned by getData()?
Hi There,
I've been thinking about a basic solution to this problem for a little while. We've got a situation where the ViewObjects will have to change frequently. I've wanted to run it past someone... so here goes:
I'm thinking of creating a generic ValueObject that can be spat out of any bus component. The view object will hold a Hashtable of name/value pairs to function like properties in a bean. The data could be pulled out of, or pushed into this object using
public String getProperty(String propertyName)
and
public void setProperty(String propertyName, String propertyValue)
methods. It will also contain a String var to name the particular arrangement of properties in the value object. ValueObjects can be created using a Factory that takes in an XML descriptor file to describe the various value objects you need in your bus domain.
Anyone see a problem with this?
How about extending the concept to other parts of an application? Could this be an alternative to ValueObjects at any level? Eventhough you may have to muck about going back and fourth from Strings.
Thanks
matt
I think that's a great idea for a changeable environment and would work well at every level.t3chi3
Thanks,yeah I thought it looked alright - nice to have some feedback though,matt
another way is to provide not only facade but also a proxy.
That is an excellent idea.
Hi Dan,let us know how it turns out for you.cheersmatt
Some thoughts on this subject (not necessarily recomendations):
Optimization usually come at a price. Most often that price is increased complexity. So I first ask why is the optimization necessary? Is your application already using up so much memory that you are in danger of gettting an OutOfMemory error when high traffic hits? Probably not, if so then the problem is elsewhere.
Other reason for the optimization may be performance. But, your application is a web application and the web container is probably in the same VM as the EJB container (if not then it should be :) ). So, you will probably not see any increased performance as a result of your optimization because the ValueObjects are not being serialized anyhow. And the EJB container is already going through the work of restoring all the attribute values whether you use them or not.
In fact, the performance of your application may actually decrease as a result of your optimization or your application will become a lot less resiliant to change (maintenance). For example, lets say you have one screen that only requires two of the 75 attributes, but then another screen requires a different set of 3 attributes. Using you optimization, you would need two trips to the EJB layer to obtain the data to display both screens. Whereas if you leave off the optimization, then a single trip would suffice.
That is not to say that I think this optimization is not worth the trouble in all cases. If you have a remote client to your application, then minimizing the RMI traffic is definitely going to result in better performance.
This is an interesting discussion. Thanks for hearing me out.
--Maciej Zawadzki
mbz@urbancode.com
http://www.urbancode.com
