10. Points of Attention

The code of this app should be extended by

We show how to do this in the follow-up tutorial JavaScript Front-End Web App Tutorial Part 2: Adding Constraint Validation.

We briefly discuss some further points of attention: database size and memory management, code clarity, boilerplate code, and separation of concerns.

10.1. Database size and memory management

Notice that in this tutorial, we have made the assumption that all application data can be loaded into main memory (like all book data is loaded into the map Book.instances). This approach only works in the case of local data storage of smaller databases, say, with not more than 2 MB of data, roughly corresponding to 10 tables with an average population of 1000 rows, each having an average size of 200 Bytes. When larger databases are to be managed, or when data is stored remotely, it's no longer possible to load the entire population of all tables into main memory, but we have to use a technique where only parts of the table contents are loaded.

10.2. Code clarity

Any damn fool can write code that a computer can understand, the trick is to write code that humans can understand. (Martin Fowler in After the Program Runs)

Code is often "unnecessarily complicated, convoluted, disorganized, and stitched together with disdain", as observed in a post by Santiago L. Valdarrama who recommends using comments when necessary, only to explain things that can't be made clear enough, but rather make your code reveal its intention through the use of better names, proper structure, and correct spacing and indentation.

10.3. Boilerplate code

Another issue with the do-it-yourself code of this example app is the boilerplate code needed per model class for the data storage management methods add, retrieve, update, and destroy. While it is good 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. In our mODELcLASSjs tutorial, we present an approach how to put these methods in a generic form in a meta-class, such that they can be reused in all model classes of an app.

10.4. Architectural separation of concerns

One of the most fundamental principles of software architecture is separation of concerns. It requires to keep the different functional parts of a software application independent of each other as much as possible. More specifically, it implies 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.

In this tutorial, 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, since we have included the method definitions for add, update, destroy, etc., which invoke the storage management methods of JavaScrpt's localStorage API. Therefore, the separation of concerns is incomplete in our minimal example app.

We will show in our mODELcLASSjs tutorial how to achieve a more complete separation of concerns by defining abstract storage management methods in a special storage manager class, which is complemented by libraries of concrete storage management methods for specific storage technologies, called storage adapters.