Closed zbeekman closed 4 years ago
Hey Izaak, the repository is about gang of four design patterns which doesn't include MVC but here is a quick explanation off the top of my head if it may help :)
MVC helps you split your application's business or domain logic from the views or rendering logic. It does so by enforcing your app to be divided in three parts Models, Views and Controllers.
Models is where all your app specific magic happens, they are responsible for all your business operations e.g. fetching data from an external source, writing to filesystem, managing state, performing database operations etc.
Views are responsible for presenting the data coming from the models. They are presentational component of your application which do not do any business specific operations and are only responsible for the representation and any supporting logic i.e. for rendering the data received from models to whatever the output medium is.
Controllers tie the models and views together. They are the entry point to your application which call the relevant models to get the data and pass it to the views for the display.
It should be noted that MVC is mainly about structuring your data flow logic on how it reaches the presentation or the user interface - it doesn't impose any restrictions on how you should structure your controllers/models or views so you may use it in conjunction with other design patterns.
You can read more about it in this original announcement and this paper by the author "Trygve Reenskaug" dating back to 1979.
Real world example for that would be me writing this explanation. My brain in this case is the model because it is doing all the "business logic" i.e. thinking about this analogy and coming up with the sentences. My hands are the view, they can write this explanation on this issue, write it on paper or any other medium and I as a person am the controller which is taking the data from the model (my brain), passing it to the view (my hands) for representation.
(A bit dull example but I hope you got the idea)
Let's take an example of a news controller
class NewsController {
public function weatherToday() {
// Call the model to get the weather results
$result = $model->getWeather($date);
// Pass it to the relevant view for display
// Notice we are not doing anything view specific here
// View has to do all the heavy lifting for that
$tv->render($result);
// or render or CLI
$cli->render($result);
// or render on newspaper
$newspaper->render($result)
}
}
class WeatherModel {
public function getWeather($date) {
// Call an API, read from database or any other source
}
}
class CLIView {
public function render($result) {
// Convert the result to relevant representation
// Display it on the view
}
}
I hope it helps :)
@kamranahmedse Thanks so much for the explanation! I hope you don't mind but I've captured your text as a gist here: https://gist.github.com/zbeekman/a613f0a1d3c1764270e6a8aa0ebbc9f2
If you like I can make it private so others can't find it, but I thought it was worth saving for posterity.
I did not realize that the goal was to address only gang of four design patterns. Thanks again for your great response!
No worries and sure you may keep it public :)
I've never seen a clear explanation of the model view controller (MVC) design pattern. I'd love to see this added to the project, especially given that my understanding of it is a bit shaky (at best). If I felt confident in my own understanding I would submit a PR, but, sadly, I do not.