BusinessDelegate and Value Object Patterns

Question

I have just embarked on the facinating world of J2EE. My questions are very simple:
Why would I use a BusinessDelegate pattern? What is it and why have this extra tier?
Finally, why would I use a Value Object? What are they? How would I use them in practice?
As you can see I am a total novice and would appreciate expert advice. Thanks in advance.

Answer 1

Why would I use a BusinessDelegate pattern? What is it
and why have this extra tier?Well, there are always some extra "plumbing" work involved when calling business services, especially if they are located in remotely hosted EJBs. You need to create your JNDI-context, perform a lookup, do narrow()-operations etc. etc.
Now this is implementation-specific stuff, that your presentation tier doesn't really need. No, it's only concerned about sending some values to the business-logic tier, and retrieving the results and acting upon them (usually formatting and displaying them to the end-user at some way).
If you wouldn't have BusinessDelegate as an extra insulation layer between your presentation and business tiers, you'd end up cluttering your presentation code with unnecesessary implementation-specific stuff. When you have a BusinessDelegate, you can isolate all the dirty work into it, make it configurable somehow, and just call it from your Servlets/JSPs/Applets whatever.
So instead of this:
InitialContext ctx = new InitialContext();
Object home = ctx.lookup( "com.company.myproject.ejb.FirstBusinessBean" );
FirstBusinessBeanHome narrowedHome = (FirstBusinessBeanHome)PortableRemoteObject.narrow( home, FirstBusinessBeanHome.class );
FirstBusinessBean remote = home.create();
// Only now you get down to the real business.
String[] initialValues = remote.readInitialValues();
// And so on.
// Some stuff like try..catch suppressed for readability.You can do something simple as this:
EJBDelegate myDelegate = EJBDelegate.getInstance( MyBeans.FIRST_BUSINESS_BEAN );
String[] initialValues = myDelegate.readInitialValues();
Finally, why would I use a Value Object? What are
they? How would I use them in practice?A value object is an object whose sole purpose is to represent a value (or a bunch of values). In the previous example, if you needed to get a list of persons from you database, and one person is represented as one entity bean, at first you'd probably end up getting a collection of PersonEntityBean's remote interfaces as a result of some ejbFindBy()-query method.
Now if you are running on a true distributed enviroment, when you iterate through this collection, displaying the persons ie. on a JSP page, every getFirstName(), getLastName(), getTitle() etc. call could potentially be a remote method call, adding a tremendous amount of extra overhead. This of course depends entirely upon your app servers implementation.
But if you replace your Remote interfaces with a simple Value object, for example PersonVO, it could be as simple as this:
public class PersonVO
    String firstName, lastName, title;
    public PersonVO( String firstName, String lastName, String title )
        this.firstName = firstName;
        this.lastName = lastName;
        this.title = title;
   public void getFirstName() { return this.firstName; }
   public void getLastName() { return this.lastName; }
   public void getTitle() { return this.title; }
}Instead of a collection of remote interfaces, you return these from your business method, and use them for displaying in your presentation logic. Simple, clean and fast.
Oh, and notice that the VO is immutable. This is a done on purpose.
Another point where a VO is really helpful that if you have ie. two different tables in your DB, represented by two different Entity Beans (Person and PhoneNumber for example), which have a relation at the database. With a VO, you can package data from multiple entities into a single object, instead of having to deal with a multitude of different entities and their remote interfaces.
I could go on for hours about this, but I guess I'll have to do some productive work as well. Anyway, these patterns are tried and tested, any believe me, they make the job a lot easier when properly implemented.
.P.