Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p><sub><strong>Disclaimer</strong><br>The whole topic is a giant mess. Especially when it comes to Web MVC. For all practical purposes it is impossible to use classical MVC pattern for web, because the view should be observing model. Theoretically you could implement something like that with WebSockets, but keeping a persistent model for <em>each</em> user is not a realistic solution.</sub></p> </blockquote> <h2>Here is what you must know about MVC</h2> <p>The most important idea in both classical MVC and MVC-inspired patterns <a href="http://en.wikipedia.org/wiki/Separation_of_concerns" rel="nofollow noreferrer"><em>Separation of Concerns</em></a>. It divides the application in two major layers:</p> <ul> <li><p><em>Presentation layer</em></p> <p>Governs the user interface. It deals with both creation of the interface and reacts to the user's manipulation of this interface. This interface might be GUI for a desktop application or HTML web page, but it also can be REST API or receiver-responder on a Mars rover. This is why a web application can implement MVC pattern in both frontend and backend.</p> <p>The mandatory parts are views and controllers, but, in context of web, fully realized views usually also use multiple templates to create the interface. </p></li> <li><p><em>Model layer</em></p> <p>This is where all the business rules and logic lives. The <strong>M</strong> in MVC is not a single entity. Instead it is a layer, which contains different structures. Some of those structures are also responsible for interaction with storage.</p></li> </ul> <h2>What are the responsibilities of controllers ?</h2> <p>Controllers are part of presentation layer, which deals with user input. In context of web-based implementations, you will usually have 1:1 relationship between views and controllers, where controller receives the requests from browser and, based on the content of said requests, alters the state of model layer and view. </p> <p>If you are using classical MVC or Model2 MVC, then that is the extent of controllers responsibilities. </p> <p>In MVP and MVVM patterns, where you have a passive view, controller-like structures are responsible for acquiring information from model layer and passing it on to the current view instance. <a href="https://stackoverflow.com/a/11878502/727208">This post</a> might provide some additional details on the MVC-inspired patterns.</p> <p>But the controller is in no way responsible for any form of business logic. If it was, it would mean, that you have a leaking abstraction, because the structures of presentation layer would be doing work, which should be in the model layer.</p> <p>Usually the controllers will the be simplest structures in you application. </p> <h2>What about the model ?</h2> <p>As mentioned before, model is a layer, which encompasses all of the domain business logic and related functionality. This layer , just like presentation layer, is made up from multiple groups of structures:</p> <ul> <li><p><strong>Domain Objects</strong><sup><a href="http://c2.com/cgi/wiki?DomainObject" rel="nofollow noreferrer">[1]</a></sup></p> <p>These structures are usually what people mean, when talking about "models". They are also known as <a href="http://msdn.microsoft.com/en-us/library/dd381412.aspx" rel="nofollow noreferrer">model objects</a> or <a href="https://en.wikipedia.org/wiki/Business_object_(computer_science)" rel="nofollow noreferrer">business objects</a>. This is where most of domain business logic ends up.</p></li> <li><p><strong>Data Storage Structures</strong></p> <p>This group would contain all of the classes, which abstract the interaction with storage (SQL databases, caching systems, noSQL, remote SOAP or REST APIs). They will usually implement some variation of <a href="http://martinfowler.com/eaaCatalog/dataMapper.html" rel="nofollow noreferrer">data mapper</a> or <a href="http://martinfowler.com/eaaCatalog/repository.html" rel="nofollow noreferrer">repository</a> pattern , but you could be using some other solutions too, like <a href="http://martinfowler.com/eaaCatalog/unitOfWork.html" rel="nofollow noreferrer">unit of work</a>. The implementation details are not so important. What <em>is</em> important is that they let you store data from and retrieve information into your domain objects.</p></li> <li><p><strong>Services</strong></p> <p>Or you could call the "components". There are high level abstractions in your model layer, which facilitate the interaction between domain objects and storage structures. The usually represent large chunks of model layer, like "recognition service", "mailers", "article management", and will provide the interface for presentation layer to interact with. </p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload