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.

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

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.