Model–view–controller (‘MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages the communication of data and the business rules used to manipulate the data to and from the model.

Wikipedia describes MVC as above. I also found a good excerpts from http://www.vojtechovsky.net that says

MVC – model view controller

MVC is an architectural pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface do not impact the data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.

After researching various articles on the internet I came up with the following descriptions of the principles of the Model-View-Controller design pattern:

The MVC paradigm is a way of breaking an application, or even just a piece of an application’s interface, into three parts: the model, the view, and the controller.

MVC was originally developed to map the traditional input, processing, output roles into the GUI realm:

Input --> Processing --> Output
Controller --> Model --> View   

Model

The model is the part of the component that encapsulates the application’s data. It will often provide routines to manage and manipulate this data in a meaningful way in addition to routines that retrieve the data from the model. In our case, the model will contain methods to add, remove and update information about the books in the database. It will also contain methods to retrieve the list of books from the database. In general, the underlying data access technique should be encapsulated in the model. In this way, if an application is to be moved from a system that utilizes a flat file to store its information to a system that uses a database, the model is the only element that needs to be changed, not the view or the controller.

View

The view is the part of the component that is used to render the data from the model in a manner that is suitable for interaction. For a web-based application, the view would generally be an HTML page that is returned to the data. The view pulls data from the model (which is passed to it from the controller) and feeds the data into a template which is populated and presented to the user. The view does not cause the data to be modified in any way, it only displays data retrieved from the model.

Controller

The controller is responsible for responding to user actions. In the case of a web application, a user action is a page request. The controller will determine what request is being made by the user and respond appropriately by triggering the model to manipulate the data appropriately and passing the model into the view. The controller does not display the data in the model, it only triggers methods in the model which modify the data.

Joomla! MVC Implementation

In Joomla!, the MVC pattern is implemented using three classes:

1. JModel
2. JView
3. and JController

These all 3 classes are interrelated.

Ok after preliminary discussion on what MVC is, let us develop a simple component that will collect feedback from a user. That is we are going to build a simple feedback component using MVC in joomla. This tutorial will be split in several parts as I may not be able to write the whole process in a single sit.

Let us first write a small requirements for the component. This will be used as a guideline to create the component. The major feature of the component will be:

1. The feedback should be categorized. That is feedback will be posted in categories. Hence there should be a category manager to manage categories.
2. The feedback should ask for following information from a user: name, email, category, feedback message. That is all! isn’t that simple?
3. The admin part should be able to moderate feedbacks sent from user. The admin should be able to delete, publish, unpublish the feedbacks.
4. Only published feedback should be visible in the frontend hence new feedback should be in unpublished state. Only admin will be able to publish the feedback.

I chose to include category manager to illustrate how we can split controllers into many and make them work together. This splitting of controllers will seem necessary for larger components. You will thank me for that later.

This ends the first part of the tutorial. I will write about the file structure and the whole component in upcoming parts.