12 Tips On JPA Domain Modelling - With Existing Database - Thinking In Structs Not Objects

  1. Forget about OO, DSLs, encapsulation, think in structs. Try to as frictionless as possible export/generate the JPA-entities from the existing database. It works perfectly with Netbeans (context menu -> new entity classes from database), or Eclipse Dali.
  2. Implement a very thin facade / transaction boundary. Currently the simplest possible way is a @Stateless Bean (EJB 3).
  3. Write rudimentary integration tests with e.g. Junit. Purpose: JPA mapping verification.
  4. Execute the "Unit" tests after every change.
  5. Implement and perform load / stress tests.
  6. If your database will remain the "master", go to 1 on every DB schema change. If it is worth to invest in real objects, then:
    1. Rename the classes into some more meaningful. The attribute, class names are in general everything but not fluent. Goto 4. This change will break the JPA queries.
    2. Rename the getters / setters - even better get rid of them (this should not break the queries, unless you are working with property based access which is not recommended). Goto 4.
    3. Goto 5.
    4. If the JPA entities still do not look right, try to apply some JPA tricks like mapping a JPA-entity to several tables, or even map JPA-entities to DB-views, to improve the situation. Goto 4.
    5. Goto 5. Compare the results with 9.
    6. Remember everything what you forgot in 1 again. Now your domain objects are semi-objectoriented. You could even start with OO-modelling.

Disclaimer: The gotos are actually gosubs (for ZX Spectrum / C64 geeks :-))

[Rich and anemic domain objects are discussed in-depth in the "Real World Java EE Patterns" book. See e.g. page 83 and 259]

Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition

airhacks.fm the podcast:

Stay in touch: airhacks.news.


> Disclaimer: The gotos are actually
> gosubs (for ZX Spectrum / C64
> geeks :-))
Don't forget us Atari 800 folks! ;-)

Cool that you thought of this. While reading I was already planning on complaining :-)

Posted by Daniel Schneller on February 03, 2009 at 01:05 PM CET #

Who can I contact to ask a question concerning the "Jukebox" tutorial?

I was working on it and I got to step 4

(Editing GenreController.java

1. In the Projects window, expand the Source Packages > jsf node.
2. Double-click the GenreController.java node to edit the file.
3. Add the following member field:
private Map<String,Object> searchParameters = null;
4. Change the first line of the getGenresAvailable(boolean) method to the following:
List<Genre> allGenres = getGenres(true, null);

and there is no such class.

Can i get some help with this?


Posted by Steve on February 04, 2009 at 06:10 AM CET #

Hi Adam,

I think the most hardest part of using EJB 3.0 is solving the impedance mismatch between the domain model and data model. My current project relies on "anemic" data model due to the fact that we don't own most of the tables since we are developing a sub module of an umbrella project.

My biggest question is - "How do design an effective domain model without resulting to a anemic one given a poorly designed data model which had been developer for over 3 years?"

Just imagine having an oracle database with a separate Date column to capture the day and VARCHAR2 column to capture the time!

I have resulted in different strategy such as ignoring fields in the RDMS to make life easier for EJB 3.0 meta data or performing EJB projection on large queries - But in the end, we opted to a Value Object over JDBC that passes primary key credentials for persistence operations (I know that this "breaks" domain modelling).

I hope you can give light in this pervasive problem.


Posted by Jerwin Louise Vergara Uy on February 12, 2009 at 03:38 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments