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.
Another issue with the code of this Java example app is the
code needed per entity class for the storage management
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.
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.
From an architectural point of view, it is important to keep the app's model classes independent of
the user interface (UI) code because it should be possible to re-use the same model classes with different UI technologies;
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
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.