In the last installment of this series I talked about building a module for abstracting the data storage of your web application. In that installment, I purposely avoided mentioning explicitly whether this data abstraction layer was to be a collection of functions or an proper object oriented (hereafter: OO) class. The reason was that for a data abstraction layer it doesn’t really matter if you’re using OO or something else. After all, all it needs to do is provide some functions for talking to some data storage mechanism or other. In today’s installment, however, I’m going to be more explicit: we’re going to be leaving the old school unix (”objects? we don’t need no stinking objects”) and beginner PHP programmer (”what’s a class?”) mindset behind to dive into one of the finest design (and oldest: it was originally invented for Smalltalk) patterns the object oriented world has to offer: the Model-View-Controller paradigm.
In essence, the Model-View-Controller paradigm is, like most useful software architecture concepts, nothing more than good old common sense. It dictates that you separate out the storage of data (the model) from the presentation of data (the view). The part of your program that connects the presentation to the data is called the controller. Hence: Model, View, Controller (MVC for short).
MVC is a paradigm that is inordinately well suited for developing web applications. Think about it: you’re fetching and storing data from a database or some flat text files (the model) and displaying the results on a web page (the view). The part of your program that sends the data to the web page is the controller. Even if you don’t know you’re doing it, you’re automatically using MVC whenever you’re developing a database driven web site.
The simple fact that MVC is a natural way to think about web application architecture and that MVC is an inherently object oriented paradigm is not the only reason to use OO for the framework you’re building, however. Another, more important reason, is that OO jargon is perfect for describing the mechanism of using abstract functions as a base upon which you build more specialized functionality. The rather convoluted statement “the function ‘retrieve_list_of_books’ uses functions from the ‘retrieve stuff from the database’ file to build a list of hashes that contain information about specific books” in OO speak becomes the much simpler “the ‘books’ class extends the ‘data storage class’”. Since simple, clear speech is an expression of simple, clear thought (when it comes to technical matters, of course. In politics it’s rather different), you will want to build your web application framework as a small set of objects and classes. This way the underlying mechanism of your framework becomes a limited number of simple concepts that are easy to keep in the back of your head while you’re working on the complexities of actually building a specific web application using your framework.
Which is the reason why, from now on, this series will go OO. There is no reason why the data abstraction layer from the last installment can’t remain a bunch of functions (if that is the way you built it) but if you built it in that way and you don’t actually have any experience working in an OO fashion, now would be the time to rewrite it as a proper object so you will be familiar with the OO concepts that will be thrown about in the next installment of this series, where we’ll decide whether or not we want to build a Model class.