Are there patterns for model / entity classes

Question

What is the best approach to take when you are pulling model objects from multiple datasources?

For example I have an application has has some data stored in a mySQL database using hibernate. What If I wanted to store some other objects in EC2 or Google App Engine? I understand that DAO's abstract the implementation of working with a particular data source, but what about the entities themselves?

At first I thought annotating my entities with jpa annotations was a great solution, but now it seems like i've really tied my entities down to a particular implementation. In the case of App Engine for example, some of these annotations make no sense.

It seems like i need a pure POJO class to represent my entities, entirely free of persistence logic. If I wanted to model a Dog for example (yes lame choice, but whatever).
Would it make sense to have an abstract Dog class, then define subclasses to work with particular persistence solutions: HibernateDog, GAEDog, etc.

Thanks.

Answer 1

This is a great question, even if the issue isn't new. As an industry, we've been changing the "conventional wisdom" on this subject frequently over the years. The answers you get today aren't necessarily what you'd get 5 years ago or 5 years in the future.

In picturing how I'd like to handle this item, I'm wondering about some things you haven't stated: is your app the "system of record" for Dog entities? What other subsystems/layers/apps need to know about Dog entities.

In Java, when you write brand new types like Animal > Dog, you get the following reward: the opportunity to write a whole bunch more code that knows how to interact with Animal objects and Dog objects. I'm less convinced in 2010 that this is a good idea than I was five years ago.

Are you responsible for designing the database where Dog information is stored? We used to do that all the time, but nowadays I usually find myself integrating with data records that are actually managed by other systems: google APIs, LDAP entities, data warehouses, products like peoplesoft, etc.

If you're not in charge of defining what a Dog is and how they interact with the universe, I'd look at a domain-agnostic way to model Dog information in memory. There are tons: XML/DOM, JSON, Map, etc.

The advantages of moving other people's data around in these formats are many...

• you don't have to write POJOs
• these are rich in features, documentation, and testing
• there are numerous existing APIs to transform, manipulate, and serialize these creatures
• you might get to reuse your view/controller/other code across other domains

On the other hand... if you are the system of record for Dog data, consider using interfaces instead of abstract classes. Or perhaps interfaces and abstract classes. Java only has single inheritance; tie your view/controller/other code to interfaces to guarentee the most future flexibility.