Head First Servlets and JSP, 2nd Edition

Time for a Transfer Object?

If it’s likely that a business service might be asked to send or receive all or most of its data in a big, coarse-grained message, it’s common for that service to provide that feature in its API. Commonly, the business service creates a serializable Java object that contains lots of instance variables. Sun calls this object a Transfer Object. Outside of Sun there is a pattern called Data Transfer Object. Guess what? They’re the same thing. (Yeah, we feel the same way about that.)

The client’s perspective, inside the Business Delegate:

That’s it. Under the covers, the Transfer Object is serialized, shipped, and deserialized on to the client’s local JVM heap. At that point, it is just like any other local bean.

Note

The data in a Transfer Object grows stale!

Once it’s shipped across the network, the Transfer Object is completely out of touch with its source, and begins to fall out of sync with the state of the data in the underlying database. You’ll have to decide for each use case whether data integrity/synchronization is worth the performance hits.

Service Locator and Business Delegate both simplify model components

Listen in as our two black-belts debate which pattern is better—Service Locator or Business Delegate.

Service Locator is the superior pattern. First ...