The MVC is a standard software architecture that aims to separate business logic from presentation logic, enabling the development, testing and maintenance of both isolated .
The picture below depicts the flow of information in the MVC pattern :
(1) The user triggers an event through the UI (click a button on the page or something).
(2) The controller receives the event and coordinates how things will happen on the server side, i.e. the flow goes to the objects required to perform the business rule.
(3) The model is used to represent the business information so it is called by the controller to perform the business rule that should be done. The model can also be used to send data to the view layer.
(4) After the controller performs business rule using the model it renders a new view and sends it to the user. Create an application using the MVC pattern is nothing more than to separate the logic in “packages” and make that information follow a certain path.
Information flow diagram of Spring Web MVC :
(1) A request from the user always arrives in a single servlet Dispatcher Servlet. This is a very common pattern in MVC frameworks called front controller (front controller) where a single servlet is responsible for receiving the request, delegate processing to other components of the application and return a response to the user.
(2) Once the Dispatcher servlet gets the request it must find out which controller the request will be sent. So it asks for help in the Handler Mapping. Based on the request URL Handler Mapping finds the controller.
(3) The request is then sent to the controller that will take care of the data contained therein. Once the controller receives the request it processes the data and performs some business rules of the application.
(4) Often rendered by the logic controller results in some information that should be taken back to the user (the model). Only sending information back is not enough, it must be formatted in a way that the user can understand, for that controller send it to the view. For this model and the view are encapsulated in a ModelAndView object and returned to the Dispatcher.
(5) As the controller is not stuck to just one view it sends a hint in the ModelAndView object to the Dispatcher to know which view should send the data. The Dispatcher passes this hint to viewResolver that returns the view which should be called.
(6) Finally, the Dispatcher sends the information (model) to the view (JSP page) who has just discovered. The page renders the information received and is returned to the user.
Here the original version: Original Version
A simple text editor could be designed based on MVC. Think of the string class as the model, where data is stored. We might have a class called SimpleTextView which displays the text in the stringattached to it, as it is. A class called KeyboardEventHandler can act as the controller. The controller will notify the view about new keyboard events. The view in turn modifies the model (like appending or removing text). The changes in the model is reflected on all views attached to it. For instance, there might be another view called HtmlView attached to the string object manipulated from within theSimpleTextView. If the user enters valid HTML tags in the SimpleTextView, the HtmlView will display the formatted output - real-time.
ReplyDeleteRegards
Rajan Bansal