Data Retrieval Patterns

Current Java practice has us using the JavaBean pattern for all data storage and retrieval. Most enterprise projects are insisting on it, a self-defeating practice when you think about it. Why restrict ourselves to one pattern when others can serve better in different situations? To help open up the options I've compiled a list of available data access patterns – in later articles I'll document my perceptions on the strengths and weaknesses of each one.

The JavaBean Pattern

Our favourite tall poppy – JavaBean is the standard pattern for creating plug-and-play components for external or disassociated infrastructures. All data is private and accessed by getter/setter methods, using a well-known naming pattern.

Method Access Pattern

Like a JavaBean, this pattern keeps data private and uses methods to retrieve and set. Unlike a JavaBean the method name is free-format – although it commonly has the same name as the data it refers to.

Public Data Access Pattern

If you're working in C, this pattern is all you've got. Public Data Access is also a common form for C++, but making data public has gone completely out of vogue for Java.

The Data Transfer Object (DTO) Pattern

A DTO can follow any of the above access patterns. It extends said base pattern to make the object purely data (zero logic), and loads it for transfer between other objects and services. DTO is the only pattern that truly protects the core data from harm since only copies are passed around.

What? When? Why?

Personally, I prefer to use the Public Data Access Pattern wherever possible. It's simple, clear and concise, and I know that I am accessing data without any surprises. If the data needs a little work, I use the Method Access Pattern, which looks almost the same but with braces at the end of the data name. I'm basically using the second pattern as a flagging method – it lets me know when reading code that there is more to the information than simple data retrieval. Using a data retrieval pattern in this way is lazy loading, but it does give me an indication if data from an external source requires work. For more complex business logic I would use a method name reflecting the work being done, not just the data name. I don't mind that a Public Data Access Pattern becomes a Method Access Pattern after class release, as the failures in client code are simple to change and remind me to to review those changes that the effects of less simple data access will cause. This review process is far more important to me at this level than the convenience of plug-and-play changes. The other two patterns I only use when I am forced to. JavaBean Pattern needs to be used when it's required by external libraries or infrastructures, and the DTO Pattern is a refuge for the paranoid – most enterprise level organisations, for example. DTO allows you to completely isolate the tiers by having specific classes that are only used to communicate across a single tier interface. This isolation also allows you to limit changes to data, but all at the cost of having to copy data regularly. Having said that, it is great for amalgamating or extracting data so that a module is provided with the data it needs and no more.