12. Points of Attention

The code of this app should be extended by adding constraint validation. We show how to do this in Chapter 9.

We briefly discuss three further issues.

12.1. Boilerplate code

Another issue with the code of this Java example app is the repetitious boilerplate code needed per entity class for the storage management methods create, retrieve, update and delete, and their wrappers in the corresponding controller classes. While it may be instructive to write this code a few times for learning app development, you don't want to write it again and again later when you work on real projects.

12.2. Offline availability

It is desirable that a web app can still be used when the user is offline. However, this is not possible with a back-end web application architecture as implied by Java EE. Offline availability can only be obtained with a truly distributed architecture where essential application components can be executed both on the back-end and on the front-end.

12.3. Architectural separation of concerns

From an architectural point of view, it is important to keep the app's model classes independent of

  1. the user interface (UI) code because it should be possible to re-use the same model classes with different UI technologies;

  2. the storage management code because it should be possible to re-use the same model classes with different storage technologies.

We have kept the model class Book independent of the UI code, since it does not contain any references to UI elements, nor does it invoke any view method. However, for simplicity, we didn't keep it independent of storage management code. First, due to using JPA annotations, the model class is bound to the JPA object-to-storage mapping technology. Second, we have included the method definitions for create, update, delete, etc., which invoke the storage management methods of a JPA environment's entity manager, in the model class. Therefore, the separation of concerns is incomplete in our minimal app.