When I write a program, no matter which tool I use, one problem I face is how to design the application. No matter if you use Java, PHP, or Visual Basic; if you design the application badly, you will have problems later when you try to fix bugs or enhance the product to the next version.
The MVC design pattern
MVC stands for Model, View, Controller. This is a very common design pattern used in programming today. When someone uses a MVC application, they make a request to a controller. The controller then talks to the model, which consists of business logic, to perform the action requested. The controller then processes the information from the model and sends it to the appropriate view.
By using the MVC design pattern, you will separate your business logic from your presentation HTML. This makes your application more easily maintainable because a bug can be fixed in the business logic without all that HTML display code getting in the way. Also, when multiple developers are working on a project, the developers who write HTML and CSS can work independently of the core programmers.
N-Layer, or multi-layer, applications are designed using layers that handle a single responsibility. Many applications use three layers; Presentation, Business Logic, and Data-Access. This is similar to the n-tier architecture, but the primary difference is tiers represent physical hardware, while layers represent software.
In the three-layer approach; the Presentation layer would consist of the user interface, the Business Logic would consist of objects that process Business Rules, and the Data-Access layer would talk directly to the data source. This design usually works well.
Putting them together
One of the things I found a little confusing about MVC at first was what exactly is the model? After much research and testing, I finally found something that makes sense to me.
The diagram above is the general layout that I use when developing a MVC application. Here is a brief description of the various components of the diagram:
- Model – In this diagram, the model would consist of the Services, Repositories, and DatabaseConnection layers along with Domain Objects.
- View – The view is the presentation or design elements of the application; such as HTML or CSS.
- Controller – The controller is the layer that drives the application. It processes requests from the user and sends them to the model and then returns the processed information to the view.
- Services – This layer handles requests from the controller. This is the layer that contains the business rules on how the application should function.
- Repositories – This layer performs CRUD (Create, Read, Update, and Delete) operations on the database.
- DatabaseConnection – This layer is further abstraction between the data source and the repository. It is not required, but I typically use it when I need to work with multiple databases. The DatabaseConnection layer was built to generalize between three different database drivers and use common methods to work with each.
- Data-Access layer– This layer would consist of the Repositories, DatabaseConnection, SQL Data Source and Other Data Sources.
- Other Data Sources – This could include a XML file, other database, or even a web service.
- Domain Objects – This is not necessarily a layer, just a collection of objects used to make it easier to work with the data from the data source. Notice that all of the other layers need to be able to work with these objects. An example of a Domain object might be an Employee class that stores information about an employee and is populated from a data source in the Repository. The Employee object can then be passed from each layer back to the view where it is displayed to the user.
This is just a brief overview of MVC with the n-layer approach.