Showing posts with label Model-View-Controller. Show all posts
Showing posts with label Model-View-Controller. Show all posts

Friday, October 29, 2010

What is MVC?


MVC, or model view controller, is a technique used in software. Its fundamental purpose is to build a distinction between the way the software handles data, and the way the software interacts with the user. This distinction means that the processes can be handled, developed and checked separately, which can be more efficient.
The process is based on the concept that, at the simplest level, all software carries out the same three-step function. First a user inputs data, then software processes the data, and finally the software outputs the results as a new set of data. A very basic example of this is a user typing “2+2=” into a calculator, the calculator working out the answer, and then the calculator displaying “4.”

In the MVC system, the way the computer processes the data is known as the model. The output of the results is known as the view. The input of data by the user is known as the controller. It’s important to remember that the view and the controller are the sections of the program which control the input and the output. The terms don’t usually refer to physical objects such as a keyboard or monitor.
The purpose of using MVC is to make it simpler to isolate different elements of a software process. By using the system, a program is effectively divided into three parts: the data processing, the input process and the output process. This means that changes to one part of the program can be made more smoothly without having to also rewrite the other parts of the program.
The model view controller system is widely regarded to have been pioneered in a programming language titled Smalltalk. Created in the 1970s at Xerox, Smalltalk was partially designed to teach people about the object model of computing. Put simply, that involves breaking down a computing task into separate parts and building the program around the way those parts interact. Smalltalk was also an example of dynamic programming, in which a program can be revised even while it is operating.
The MVC system is often used in web-based software such as that used in dynamic, or interactive, websites. In these situations, the view is the code, such as HTML, which is generated by the software after processing a query. For example, on a search engine, the search query box would be the controller and the results page the view.

Model-View-Controller


Flexibility in large component based systems raise questions on how to organize a project for easy development and maintenance while protecting your data and reputation, especially from new developers and unwitting users. The answer is in using the Model, View, Control (MVC) architecture. An architecture such as MVC is a design pattern that describes a recurring problem and its solution where the solution is never exactly the same for every recurrence.
To use the Model-View-Controller MVC paradigm effectively you must understand the division of labor within the MVC triad. You also must understand how the three parts of the triad communicate with each other and with other active views and controllers; the sharing of a single mouse, keybord and display screen among several applications demands communication and cooperation. To make the best use of the MVC paradigm you need also to learn about the available subclasses of View and Controller which provide ready made starting points for your applications.
In the MVC design pattern , application flow is mediated by a central controller. The controller delegates requests to an appropriate handler. The controller is the means by which the user interacts with the web application. The controller is responsible for the input to the model. A pure GUI controller accepts input from the user and instructs the model and viewport to perform action based on that input. If an invalid input is sent to the controller from the view, the model informs the controller to direct the view that error occurred and to tell it to try again.
A web application controller can be thought of as specialised view since it has a visual aspect. It would be actually be one or more HTML forms in a web application and therefore the model can also dictate what the controller should display as input. The controller would produce HTML to allow the user input a query to the web application. The controller would add the necessary parameterisation of the individual form element so that the Servlet can observe the input. This is different from a GUI, actually back-to-front, where the controller is waiting and acting on event-driven input from mouse or graphics tablet.
The controller adapts the request to the model. The model represents, or encapsulates, an application's business logic or state. It captures not only the state of a process or system, but also how the system works. It notifies any observer when any of the data has changed. The model would execute the database query for example.
Control is then usually forwarded back through the controller to the appropriate view. The view is responsible for the output of the model. A pure GUI view attaches to a model and renders its contents to the display surface. In addition, when the model changes, the viewport automatically redraws the affected part of the image to reflect those changes. A web application view just transforms the state of the model into readable HTML. The forwarding can be implemented by a lookup in a mapping in either a database or a file. This provides a loose coupling between the model and the view, which can make an application much easier to write and maintain.


By dividing the web application into a Model, View, and Controller we can, therefore, separate the presentation from the business logic. If the MVC architecture is designed purely, then a Model can have multiple views and controllers. Also note that the model does not necessarily have to be a Java Servlet. In fact a single Java Servlet can offer multiple models. The Java Servlet is where you would place security login, user authentication and database pooling for example. After all these latter have nothing to do with the business logic of the web application or the presentation.