The classic MVC (Model-View-Controller) architecture (see Fig. 1) has the View communicating with the Controller and the Model. However, this leads to coupling between the Model and View, View and Controller, and Controller and Model. A case could be made that is a significant amount of coupling. Unfortunately, coupling is the bane of software development. Additionally, coupling makes software hard to change. Instead, an N-Tiered approach to the MVC pattern was created to alleviate the coupling and create a more flexible design.
The View Layer
Additionally, a view can contain code to iterate through a collection or an array. This is often needed to create tables.
The Controller Layer
The second layer consists of a single controller per view. Each view has its controller and controllers do not communicate with other controllers. Controllers route the view’s request to the model. Additionally, the retrieval of data from POST and GET is also performed by the controller. Lastly, the controller determines the overall flow of the application. This includes reacting to form submissions and also redirecting to other pages.
While in the controller, the method names will often match the domain of the web. For example, the check-boxes will have an “is-checked” status. However, when the control of the application passes through the controller and into one or more models, the method names and class names will change to match the domain of the problem. Therefore, within the models layer, no references to the web application domain exist (e.g. references to checkbox statuses).
The Model Layer
Below the controller, there is one or more models. Sometimes, the model will communicate directly with a data accessor. Other times, the model will communicate with other models in order to implement the application’s business logic. In any case, the logical topology of the of the models layers is very domain specific.
The Data Access Layer
After the models layer is the data access layer. The data access layer provides one ability. That ability is to store and retrieve data from the database (persistence layer). Therefore, the functionality provided by the data access layer is limited to CRUD functions (Create, Retrieve, Update, Delete) and searching functions (e.g. search by last name).
The data access layer is kept as simple as possible for several reasons. First, if the database is changed, then the amount of code that needs to be changed can be kept to a minimum. Second, since the data access layer is kept so simple, specific features of a particular database vendor that can create lock-in can either be avoided or encapsulated. Lastly, the data access layer provides the ability to move away from a database altogether. Theoretically, the data access layer could interact with a flat file or a network connection.
Data Transfer Objects
The last piece of the N-Tier Model-View-Controller architecture are the data transfer objects. These objects provide the ability to transfer highly coherent chunks of data between objects in the various layers of the application. Obviously this creates a high amount of coupling between them and any object that uses them. Therefore, these objects are always kept very simple. Typically, they are limited to getter, and setter methods.
Experience with this type of software design architecture has shown higher levels of code reuse as the code base grows (see Fig. 3). The highest levels of code reuse occurs due to the data accessors.
The reason for this is because most web applications will persist a large fraction of its information to the database. The model layer also will have a significant amount of code reuse as well. This is due to the models being both highly cohesive and highly decoupled.