The code of this app should be extended by
adding some CSS styling for the user interface pages and
adding constraint validation.
We briefly discuss some further points of attention: database size and memory management, code clarity, boilerplate code, and separation of concerns.
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
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
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.
Another issue with the do-it-yourself code of this example app is the boilerplate code needed per model class for the data storage
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.
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
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.
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.