Why i prefer POJOs to maps for domain objects

Firstly, domain classes and DAOs are two separate issues. With Hibernate, for example, you can use POJOs or maps, and you can have multiple DAOs or one generic one. So why do i prefer POJOs…

1. They are type safe

Your IDE will flag a problem as soon as you type it.

2. Code is more concise and readable

Readability is key. Developers read 10x more code more than they write.

// The POJO
Article article = new Article(1234);
article.setHeadline(“Cheryl Cole Arrested”);
smallImage = article.getImageOfWidth(250);
mainImage = article.getMainImage();

// The Map
Map<String, ? super Object> article = new HashMap<String, Object>();
article.put(ArticleKeys.ID, Integer.valueOf(1234));
article.put(ArticleKeys.HEADLINE, “Cheryl Cole Arrested”);
image = ArticleHelper.getImageOfWidth(article, 250);
mainImage = (Image) article.get(ArticleKeys.MAIN_IMAGE);

3. Code is more concise and readable in JSP

${myPojo.author.name}
${myPojo.pubDate}

<%@taglib prefix=”met” uri=”…” %>
${myMap[‘author’][‘name’]}
${met:pubDate(myMap)}

<!– For draft articles there won’t be a published date so we want to fallback to modified date –>

4. They can encapsulate domain logic

This keeps code where it belongs. And stops it sprawling where it shouldn’t. Some basic examples

• Validation rules, for example. JSR-303 provides annotations which can be used with Spring and Hibernate.
• POJOs can have proper toString methods – useful for debugging and logging. In contrast, maps will splurge all their entries, in a random order, including the whole article body text. (BTW, that will probably kill your log files and potentially your app).

5. They abstract from the relational schema

Consider an article with images.

• Maybe images are stored as separate rows in an IMAGES table
• Maybe the images are stored in the article body text
• Maybe images are stored in the ARTICLES table in a column of type “array”

6. They are easier to debug

It’s hard to find a specific Map entry in a debugger.

7. IDE support

Code completion. Find references. Refactorings. Javadoc tooltips.

8. POJOs are easier to profile

What’s eating up all you memory and killing your app? Using POJOs, a profiler will tell you how many Article objects there are, how many Category objects, etc.

Using maps, a profiler will tell you… guess what? You’ve got a lot of map entries. Not much help.

9. They are more expressive

Class models are more expressive than relational models. Classes can extend other classes. They can implement interfaces. Objects reference other objects. Java has annotations and javadoc. This all helps express the domain model. And the domain model is the heart of the application.

Database tables just have foreign keys.

10. They perform better

There are no lookups. You don’t need to worry about the number of entries, or the capacity, or the load factor, or the performance characteristics of your chosen implementation.

Also, consider that JDK maps don’t know about primary keys. This means…

• Slow hashCode methods = poor performance with collections
• Slow (and semantically incorrect) equals methods

11. They are the de facto standard

12. They have a versioning strategy

This applies to serialized data (e.g. caching to disk) and hot-swap code changes.

13. They can use primitives

Simple. Efficient.

Finally…

A few false arguments for using Maps…

1. You end up with lots of domain classes. The same is true of maps, you still end up with a class per entity (for key constants and helper methods).
2. POJOs result in more code. No, the code example above shows that even if the POJO itself is more verbose, the code using it (services, controllers and views) is more concise.
3. Writing and testing POJOs is too much effort. Your IDE can generate the boilerplate code. There are libraries to auto-test accessors and Object methods.