Your App's Core Data Model: Theory and Practice

After yesterday's post about JOOQ, I wanted to return to the idea of how we go about creating our core data models in the real world.

I like UML modeling because it helps you to communicate design ideas.  I must immediately qualify this by saying that I have always found so called "round-trip" modeling to be pure folly.  I use models (class diagrams, use case diagrams, deployment diagrams) to communicate ideas and then I let the diagrams go; it is counterproductive to try to use UML diagrams as a kind of policy enforcement tool.

So, UML is all about theory, in my view.

I used to use MagicDraw UML, but recently I switched to GenMyModel because it is simple to use and it is far more cost effective.  Plus, GenMyModel has some useful code generation features.  For the record, I have no relationship with any vendors mentioned here.

Please consider the above diagram of a too-simple access control model.  The model itself is publicly visible on GenMyModel, and the generated code is on Github.  Feel free to explore them and star, etc as you feel appropriate.  GenMyModel lets you save your model straight to Github (shown below) repo, or you can download a Zipfile.

You can generate JPAs (along with a Maven build), or you can roll the dice and generate an entire Spring Data Rest implementation.  I decided to roll the dice and go with the REST API.  Once you download it, you can unpack the zip file and "mvn jetty:run" in the root folder.  Then open localhost:9090 in your browser and you should see something like below.  Pretty cool, right?

Another great thing is that you can open this project directly in your favorite tools.  I use Intellij.

So this was pretty easy, right?  But then working with simple models is always easy.  Any of the following approaches works fine for small scale work:

  1. Hand code JPAs and let your tools help you with schema generation, etc
  2. Use a diagramming tool and generate JPA or a full REST implementation (this post)
  3. Direct SQL (if you are using a relational database!)
    For larger apps in the real world, many in the Java space will argue that the current best practice is #1.

Today, we looked at #2.  Not bad.  Fun, even.  But would you do this for a model with 50 classes?  Would it scale?  I am not sure that I would have the patience for it.

I will argue that, with the arrival of JOOQ, approach #3 is now the best way to work with large and complex relational models in Java land.

To come back to the topic of this post: "Theory and Practice": I think that it will soon become clear to many Java developers that, #3, "database first" modeling is enormously powerful, especially if you can use your awesome Java IDE to help you write SQL queries via JOOQ that might take you weeks to figure out using approach #1.