CarrierWave on Hibernate Wiki

I posted comments, but I am reposting them here so the hyperlinks work.

----

Actually, CarrierWave was developed so that client and server side developers would not be using the same objects. The fact the Images are DTO's is a side-effect. See Conway's Law for some background.

Specifically, I've found that if client and server side developers use the same objects, the development effort won't scale. That is, they can't work as independently.

A simple example would be the haggling over if a getter should sort the returned collection when it doesn't solve a business problem but a presentation problem.

A bigger example would be the client side having to make available all the libraries and classes used on the server. Why should a GUI object editor or JSP/Servlet engine need to have hibernate in the classpath if the server is out of process. And how do you communicate what methods shouldn't be executed or values that can be changed in the client process space.

The Image classes are type equivalent to the server side business objects (Imageable) they mirror. They are based on the Imageable type's class structure and any meta-data placed in the javadoc comments. An Icon is similiar to an IOR. It can be used on the client and server to identify an object instance, and is portable across process spaces.

CarrierWave, being an implementation of the Horizontal Vertical Meta-Data pattern (hence the name CarrierWave), is best served through code generation, even though i'm not a big fan myself. The generated Image classes have a fair amount of meta-data so reflection isn't necessary to manipulate them. This is what some call omnicompetent programming. It's even better than reflection since from an Image class, you can find the contained type exected in a collection field. Or you can determine if the field is derived and read-only, if the field is a literal/scalar type, or another Image type.

The real power here is that client side tools can be written to work against the 'horizontal' interface and thus can be re-used across applications since there is no coupling to the business domain (vertical) interfaces. That is, you can build your applications with type-safety or without it.