In my previous post, I mentioned the structure that we’ll be using for the Exam View project. In our system, the data layer is the back end being used by Exam View. It could be UNITe or another system, but it’s essentially an opaque box. It’s the job of the model layer to communicate with the data store and translate this data into Exam View’s internal format.
To this end, different data layers will require different model layers to read from them. Also, different presentation layers will need to work with different backends depending on the situation. In the Exam View system, the presentation layer is the user-facing side that people will interact directly with. The model layer is the glue that keeps the system together, performing functions when the presentation layer tells it to, and translating things from the data layer.
To make these different layers interchangeable, we need to rely on the model layer (and, to an extent, the presentation layer) being able to do certain things. For example, if we know the model layer has a function called ‘get_student_records’ that takes in a student ID and returns a neatly formatted set of results, it becomes easy to swap in different presentation layers and model layers and be certain that they will work together.
We do this by using something called an interface class. These interface classes dictate that everything that calls itself a model layer must make certain functions available to the presentation layer (and vice versa).
Ensuring all code conforms to these structures has other benefits. This clear structure between layers makes it easier to know where to begin when writing a new model layer or presentation layer. It also makes it easy for Exam View developers to modify someone else’s code, since they will know the basic structure that any model tier should take.