Blogging Pubbitch

One of the things that has slowly managed to seep into my mind is the idea of Value Objects. Traditionally, these are viewed as dumb chunks of data that are used to transfer information between tiers in a web app, mainly to reduce the number of network data transfers (which are slow)

The thing is, I've always seen Value Objects as being between a user facing view and the controller (that is, for example, between a JSP and a servlet) but that's not all that they are used for. One way of looking at O/R mappings is as a mechanism for defining Value Objects that get passed between the app and the database. This raises the question as to where "business methods" should be put (you know, the methods that act on the data)

My gut instinct is to keep the two separate, putting the data in one class and the methods that act on this data in another. Consider, if you will, a Big and Nasty J2EE application. Granted, I've not seen many of these, but the design espoused by the books I've read suggests using a Session EJB in front of the (B|C)MP beans. This is normally presented as a means of keeping down the number of network based calls, but it leads to a certain degree of separation between the persisted data and the methods that act on this data.

I suppose that it's possible to argue that you can never fully quantify the number of ways in which your classes will be used, so keeping down the number of methods on the classes that hold the data can only be a Good Thing, but that's not the real reason I have for wanting to keep the objects used to represent the persisted data as dumb as possible. The real reason is that I'm Lazy, in the Larry Wall sense.

The two O/R tools that I've used most (Hibernate and CMP2) both use XML documents to describe the persistable classes and the relationships between them. This information is enough to generate skeleton implementations using XSLTs. It's also possible to define other useful "stuff" using XSLT from these same descriptors, especially if you are willing to write O/R descriptors for classes that are not going to be persisted, such as the Value Objects that you are going to be passing between your servlet and your display tier (be it JSP, Velocity, XML or whatever) Why? Because it is possible to write XSLTs that can be used to create the form that will be used by the front end, an abstract class that your Webwork Action can inherit from and the Value Objects themselves, amongst others. Make a change in one place, and it's reflected in all those other pieces. For free.

Now, that sounds like being properly Lazy to me.

The last time I looked at Cocoon I found it slow and cumbersome, with what (at least then) appeared to be a formidable learning curve. Of course, the machines that I use now are about two to four times faster, with a slew of memory so perhaps the speed won't hurt so much this time.

The question is, how long will it take to get up to speed on Cocoon? Comments such as:

In getting started with Cocoon, one must learn not only a number of concepts, but a number of details as well.

hardly fill me with confidence.

Later: Ahhh... it looks like getting intimate with Lucene might be useful too.

The reason for wanting to get to grips with both of these? Because they're being used on a project at work and I hate not being able to understand how everything fits together. That, and because I hear various folks talk about Lucene in a favourable way.