Last time I talked about how the Model View Controller paradigm (MVC) and object orientation (OO) were a perfect fit for writing your own web application framework. In today’s installment I will discuss the Model part of this model.
Now if you’ll recall, in part two of this series I decided that a web application framework needs to create, read, update and delete (CRUD) bits of data from some sort of storage mechanism, and I wrote a module (which was, in fact, an object, though it doesn’t need to be) that exposed abstract CRUD functions for a given type of data storage. Then, in part three I said the Model part of MVC is the part that determines how data is stored, retrieved and manipulated. Strictly speaking, therefore, we already have a base class for the model part of our web application framework. Every time we need a new data type (a list of books, for example), we can simply subclass this data abstraction class as presumably that will give us all the methods we need.
However, it might be a better idea to create a separate base model class instead of simply extending the data abstraction layer every time we build a new model. There are three reasons for this. First, when thinking about the model part of our application, we really don’t want to be bothered by the fact that the basic operations (create, read, update and delete) are in fact database operations. Now of course our data abstraction class is, in fact, very abstract (as you’ll recall it contains methods that automatically compose queries for simple use cases), so this, by itself is no reason to build a separate model object. The second reason isn’t terribly convincing either, as it’s the often heard statement that you should abstract out your data storage mechanism so you can simply swap it out and replace it with a different one should it be decided at some point in time that the data that is currently in a MySQL database (for example) will now be stored in a series of flat text files. I have been developing web applications for a little over seven years now and never once have I run into such a situation. Should you ever come across it, however, I can assure you that rewriting a bunch of models to deal with a different data storage mechanism will be the least of your worries as you’re trying to coerce a database dump file into a set of flat files on the server.
There is, however, a third reason why a separate model class is preferable, and this one actually makes sense: a model in an MVC web application might need to do other things besides interact with the data storage mechanism. The prime example of this is logging: you don’t want to provide all sorts of fancy logging facilities in your data storage abstraction class, but you probably do want it in the model of a web application.
If logging isn’t enough reason for you to create a separate model class, by all means don’t. Ultimately, it isn’t very important. What is important is that you have a base class for your own models that proves create, read, update and delete methods. With that class we can start building controllers, which is what we’ll do in the next installment.
Previously: