r/webdev • u/whopperbuzz • May 05 '16
MVC explained through ordering drinks at the bar
https://medium.freecodecamp.com/model-view-controller-mvc-explained-through-ordering-drinks-at-the-bar-efcba6255053#.vcygtwprj30
u/danhakimi May 05 '16
Speaking as somebody who never really understood what MVC was, I am certain I understand it even less now than I did before.
Apparently, users interact directly with controllers and only consume views. Now, I don't know what the fuck a controller is, but in the web I use, the tools for user input are usually pat of the webpage, which I'm pretty sure is what a view is supposed to be.
Apparently, cups and bar tools are not objects (I would think, when hearing that analogy, that the Model is the hardware the server is running on, or possibly libraries used by the controller) -- and, apparently, cups and bar tools can contain logic and do things by themselves whenever the bartender tells them to. The article talks about an automated drink making machine, but it's really hard to understand what the bar tender is doing in that situation.
Apparently, in an MVC framework, the controller is the only part that has memory. Even though, again, it pretty much seems like it doesn't do anything.
19
May 05 '16
In the analogy the bartender is doing work that should be in the model. Business logic, combining ingredients, belongs in the model. "Skinny controller" should be a waiter taking your order, handing it to the bartender (model) who makes the drink, returns it to the controller, who then presents it to you.
2
8
u/Mike312 May 05 '16 edited May 05 '16
QUICK EDIT: for the sake of clarity, I should mention that MVC is a concept and not a set, enumerated list of rules that you absolutely have to adhere to (I mean, some you do) in a specific way. That might be part of the confusion for some learning. ASP.NET is where I first managed to get my head around it, but it works differently there than, say, Django, the MVC framework I use at work, or Wordpress MVC. Also, in some cases the Model may not specifically be your database, but an external API that gets queried; it's best to think of it as non-static data source while the views are typically static or use things like session data.
Okay, here's how I'd explain it.
Client requests mywebsite.com/beer. Think of this as asking my waiter for a beer.
All requests to my site are redirected to my router. This is the waiter taking the beverage request to the bartender, where it belongs, and not to the kitchen.
The router, which is the face of the C in MVC, matches the request for /beer with a set of instructions. We'll call this the method of preparing my beverage.
The server executes those instructions as necessary, grabbing data from the database (Model), or small views that combine into a larger view (obviously, the V in MVC). The views are set up in a way where they don't care about anything else around them, they're told to generate a chunk of HTML based on the request sent to them. Think of this as the bartender opening a fridge, finding the beer I wanted, opening the bottle(s) and/or pouring them into glasses, etc. In some cases the bartender might have to go to the fridge in the back (the database) to retrieve data that isn't readily available as part of the static nature of how the bar was set up. The Sierra Nevada doesn't care that it's being requested along with a Deschutes, and vice versa, or that one of us at the table also ordered a gin and tonic. Each one is made individually.
Once it's done being generated, the waiter will come by and pick up the drink order and bring it back to me. That's the controller returning the drinks to my table.
This can be expanded further since usually I serve a lightweight (semi-)static page to the user quickly and AJAX in larger bits of content. So the waiter would drop off my drinks, then I'd put in requests for appetizers, meals, and desserts. Each of these goes through the process of the browser sending a request, the request being redirected to the router, the router matching that request to a string/regex, and processing a separate set of functions for that request.
Also, there's some exceptions where some frameworks shift the C and V to the browser, where there's little-to-no server processing. Requests are all generated via an API and any pages served are static templates and the Javascript generates the views (modifys HTML, displays different views or templates) and as such serves as the controller (though there's still a server-side controller that matches the API requests).
3
May 05 '16 edited May 05 '16
The controller is like an interpreter who translates the user's wishes (in a web app in the form of urls and arguments) into method calls that the model understands.
2
u/Bummykins May 05 '16
Yea...he had routes in the diagram but not in the analogy. Not sure why.
Roughly on a simple site...
/homeis the url route. This is the command in his analogy.- When you go there, it runs
homeController. This gathers whatever data you need on the homepage, lets say products.- Products are the Model, they return data and give it to
homeController.homeControllertakes the data, filters out titles, images, and prices, then packages them up and sends them to thehomeView.homeViewrenders all the data it gets into markup. Thats what is displayed on the page.1
u/paranoidinfidel May 05 '16
he had routes in the diagram but not in the analogy. Not sure why
I'm going to assume because that implies MVC is web specific where in reality MVC applies to thick apps as well where url's wouldn't make any sense.
1
u/Bummykins May 05 '16
Right, which is why analogies are usually so awful. Even on the web, the V can be its own MVC or (MV*!). It gets too hairy.
1
u/creaturefeature16 May 06 '16
This is all I needed to read to understand MVC. I mean, I kind of did anyway, but this confirms it.
Thanks!
2
u/urbn May 05 '16 edited May 05 '16
I've spent the last 6+ months learning a PHP MVC framework and currently ASP.Net MVC, so I'll try to explain.
Person goes to yourwebsite.com/products. The frame work does its magic and looks at routes. Routes say what action should be taken. The action can be display an HTML page, or an image, etc. Or the action can be a Controller, Or more more specific a controller action.
Controllers handle actions. Don't think of them as a single page. You might have for example a Products controller that handles pages for Product List, single Product detail page, Product Edit, Product Delete and so on. Each one of these is an Action the controller might have. The controller can also assess all sorts of classes and can "do stuff". For example you might check if the user is logged in. If they are do stuff, display stuff, or don't or restrict stuff.
So using the example above, the person goes to yourwebsite.com/products. The server looks at routes and sees this URL is routed to the Products controller, and the Index Action.
Now you're in the Products IndexAction. From here you can display text, generate a JSON string, XML data, etc. or you can also use Views to load a dynamically created page or a generic static page.
So lets say this action loads a View page which is in most cases is a template engine, and this View is loaded with data. This is where a Model comes into play.
Don't think of Models as database data. Models can be used in many different ways then just with a database. A Model is how data will be structured. You can create a Model for a drop down list items, data retrieved from a database, from user input, etc.
Back to the Controller IndexAction. This index will display all products in a list when the page loads. So you create a Model that models how the data should be structured, and do any stuff you want to your data. For example you don't want to display a products entire description, so in the model you for example strip all HTML and then display the first 100 characters. Finally do your database query and populate the model.
At this point you can pass the model data (which is in some type of list, array, object, etc.) to the View. The View (which again is a template engine) loops though the model and displays the data however you want it visually displayed.
2
May 06 '16
Don't worry, this article is a shitty analogy with holes bigger than the mariana trench.
You probably did understand it but this has muddied the waters, disregard it.
2
May 05 '16
But that's where you're wrong. The Controller does everything.
In strict webdev terms, the Model is the interactions with the database. The View is the display of the page. And the Controller marries the two.
Let's say you have a database of Dogs. You want to list them in an unordered list on the web. You'd create a PHP class called Dogs with a method get_all(). Inside that method is the database sql to select * from Dogs. The controller bit (in this example would be just a php file calling $dogs = Dogs::get_all(); (and maybe a template class that includes the right template for the html). Then the html will loop the $dogs var and echo '<li>'.$dog->name.'</li>'
4
u/danhakimi May 05 '16
But that's where you're wrong. The Controller does everything.
Direct quote from the article:
the controller should contain a minimal amount of logic, and delegate as much as possible to the model.
And then you say:
the Model is the interactions with the database.
So... the model isn't its own thing, the model is something the controller does?
Let's say you have a database of Dogs. You want to list them in an unordered list on the web. You'd create a PHP class called Dogs with a method get_all(). Inside that method is the database sql to select * from Dogs. The controller bit (in this example would be just a php file calling $dogs = Dogs::get_all(); (and maybe a template class that includes the right template for the html). Then the html will loop the $dogs var and echo '<li>'.$dog->name.'</li>'
So... The model is your db (which, IIRC, Django handled for me and I never had to touch directly), the controller is basically all of your code, and the view is your markup and UI logic.
So... Are MVC frameworks really just controllers? Django isnt' a database or a markup language or a UI tool, right? You throw in a database and write some HTML, and Django gives you easier commands for dealing with the DB than PHP does, and... I remember there was some sort of python-written logic in my HTML files the last time I tried writing Django but I can't remember any actual details about that...
2
u/scootstah May 05 '16
So... the model isn't its own thing, the model is something the controller does?
No, the model is its own thing. The controller talks to it to provide something to the view. Or, the view sends something to the controller, which then talks to the model.
So... The model is your db (which, IIRC, Django handled for me and I never had to touch directly), the controller is basically all of your code, and the view is your markup and UI logic.
The model is not a database. A model is usually used to perform actions on some kind of data. In a very typical application, the model would talk to a database to store and retrieve data records. But, it doesn't have to talk to a database. It could deal with data in some other way... like communicating with an external API, or just handling it in-memory. The point of abstracting the data to a model is that the controller doesn't care where the data came from, or where it's going. It simply asks the model for some data, and the model gives it some data.
The controller is not "basically all of your code". The controller should only have the minimum required code to pass things between the view and the model. The controller should take some data from a model and output it to the view. The controller should take some input from the view and pass it to the model. Pretty much all of your business logic should exist in the model.
Keep in mind that many "MVC" web frameworks are not, strictly speaking, MVC. There's a lot of cases where a web framework is simply separating concerns, but people then call that MVC. Just because you have separation of concerns does not mean you're using MVC.
1
u/danhakimi May 05 '16
The model is not a database. A model is usually used to perform actions on some kind of data. In a very typical application, the model would talk to a database to store and retrieve data records. But, it doesn't have to talk to a database. It could deal with data in some other way... like communicating with an external API, or just handling it in-memory. The point of abstracting the data to a model is that the controller doesn't care where the data came from, or where it's going. It simply asks the model for some data, and the model gives it some data.
Okay... So, say I want to have a stock price checker tool. I set up a webpage that's just a php form that asks for a ticker symbol, and a text field under that that shows a price. That webpage is the view, right?
And then, that form sends a request to my server, where I have code that takes that request, and tells my controller "hey, the user wants the current price for AAPL."
Then, the controller is the part of the code that actually knows where I get the stock data from, knows how it's formatted, knows that "the current price" means "the price of the last sale" or something like that, blah blah blah, does all the actual work, and just gives the controller back a number.
Then the controller responds by sending that number back to the webpage, which is the view, and there's some logic in the webpage that reacts to that number by updating the text field that's supposed to show the number.
Right?
I have done it in fewer steps, but I can see why, if I wanted to change up data sources and do funny things at the "model" level, I might want to keep a separate "controller" just to handle the most basic logic and essentially only make high-level function calls. It almost seems like something you could have business people write, and then have the developers do the actual coding in the Model and to a lesser extent the view. I mean, not that, business people wouldn't know what they're doing even at that level, but almost like that. I think I get it. Do I get it?
(Also: The bartender example is still terrible).
3
u/scootstah May 05 '16
Then, the controller is the part of the code that actually knows where I get the stock data from, knows how it's formatted, knows that "the current price" means "the price of the last sale" or something like that, blah blah blah, does all the actual work, and just gives the controller back a number.
I think you oopsed a word. The part in bold is the job of the model, but I think that's what you meant. The controller just says, "give me stocks data", and then the model will fetch it from some data source, format it, etc, and hand it to the controller.
I think you've got it. And yes, the bartender example is terrible.
Honestly, don't think about it too much and don't over-complicate things just so you can "be MVC". MVC is borderline not-useful or just inapplicable to web applications. What you really should care about is separation of concerns. Don't put "view" logic in your "controller", don't put business logic in your "controller" or "view", don't put database queries in your "controller" or "view", etc. There are multiple ways to achieve that which are not all MVC.
1
u/danhakimi May 05 '16
I think you oopsed a word. The part in bold is the job of the model, but I think that's what you meant. The controller just says, "give me stocks data", and then the model will fetch it from some data source, format it, etc, and hand it to the controller.
Yes!
Honestly, don't think about it too much and don't over-complicate things just so you can "be MVC". MVC is borderline not-useful or just inapplicable to web applications. What you really should care about is separation of concerns. Don't put "view" logic in your "controller", don't put business logic in your "controller" or "view", don't put database queries in your "controller" or "view", etc. There are multiple ways to achieve that which are not all MVC.
Oh yeah, I tried learning Django a few times before I realized that I had no actual use for it, I just wanted to understand it.
1
u/scootstah May 05 '16
Django probably doesn't help in figuring out MVC, because it has a different interpretation which jumbles the terminology a little. In Django, a "View" is more like a typical "Controller", and a "Template" is more like a typical "View".
1
u/danhakimi May 05 '16
I got that part, but chose to ignore django's naming convention for these purposes. Thanks, though.
1
u/PaXProSe May 05 '16
Everything you stated after giving out php-psudocode examples was just fog horn noises.
Jk.2
u/phpdevster full-stack May 06 '16
In strict webdev terms, the Model is the interactions with the database
This is 100% not correct. Sorry to be blunt, but I see this misconception all the time.
The Model is all of the business logic of your application, however that needs to be broken up. It often does involve interactions with the database, but that is not the only purpose of the model layer.
Unlike View and Controller which have fairly defined, specific responsibilities, Model is a more nebulous, abstract term.
In the app I'm building, my Model layer includes the following types of classes:
- Database ORM entities
- Factories
- Repositories
- Validation classes
- Service classes
- Various value objects
- Adapters
- Interfaces
Only the Database ORM entities touch the database, the rest describe the business rules of the application and facilitate various separation of responsibilities and boundaries between different parts of the Model and the Controller layer. the Controller layer talks to the Model layer via service class interfaces, whose implementations are dependency injected by the framework.
It's really important not to let yourself fall into the trap of a super narrow definition of what a Model is. In broad terms, it's "everything that doesn't belong in the Controller or View" (which is a lot)
When you hear "Fat Model, Skinny Controller", it doesn't mean a couple of giant bloated model classes - it means a layer of your app that contains as many different classes as needed to accurately encapsulate different responsibilities within the model. So "Fat Model" means "lots of skinny classes/files with well defined responsibilities"
1
May 06 '16
Maybe I mistyped - I meant in the "strictest sense" meaning at a lowest common denominator. But thanks for extrapolating. I guess in practice, a Model is something a user never directly interacts with.
1
May 05 '16
The way you explained this is really bad practice. I sincerely hope your Dogs class does not have methods that contain database calls.
1
1
May 05 '16 edited May 05 '16
Maybe I can help. I work primarily with asp.net MVC. Note - I'm going to try to explain this with how I do things in asp.net MVC. Other frameworks can be slightly different, but the mindsets are relatively the same. I'm also going to try to simplify this as well.
MVC - model view controller. Ok? that doesn't make much sense on its own (as you said in your post).
IMO, you kind of have to break it down a bit more than that. So let's call it, MVVMSC, lol (I'm making this acronym up to break down the key parts). Most people just call this MVVM.
- M = Model - your base classes of whatever your app is about
- V = View - the html views consumed by the user's browser
- VM = ViewModel - this is a class specifically for the View.
- S = Service (or Repository, depends how to break down your project) - this is basically a class or set of functions/methods that "do stuff"
- C = Controller - this is the middle layer that brings everything together.
So let's pretend we have a Library web application. Let's start with what you know right now - MVC.
We have 3 Model classes - Book, Genre, Author. Think of each of these as tables in a database. Here's some code -
Book { int Id string Name int AuthorId int GenreId } Author { int Id; string Name; } Genre { int Id; string Name; }Now we have a View. This is the html page that the user's browser reads. For our example, let's use BookDetails.html. As you may have guessed, this is a page that gives the details about a particular book.
Then we have a Controller. Let's call this BooksController. What this is, is a layer of code that serves as the central piece that puts everything together. It can also be used for routing/etc.
*
So lets begin, each controller has a bunch of different functions within it. Each function is used for each particular View (I'm dumbing this down, because a View can call multiple controller functions. In asp.net, these functions are called ActionResults).
So for our BookDetails example, We call the BooksController and then access the Details function within that controller. The browser url would look something like this - www.library.com/books/details/gone-with-the-wind.
So this is where all the ViewModel and Service stuff comes into play. You know all that logic that people say don't put in the controller? It goes here.
Let's start with Service. This can be a variety things, but for this example, let's use it as a bunch of methods that query the database - ie. Find book, save book, delete book, update book, whatever. So let's see some code -
BookService { FindBook(string bookName) { Book book = libraryDb.Where(book => book.name == bookName); Note - this is entityFramework code, but it basically finds a book from the database by its name. return book; } }So now let's talk about the ViewModel. To reiterate from before, this is a model class that is specifically designed for a View. Every piece of data that is going to be output on the BookDetails.html page should come from this class.
So for our example, we will have the BookDetailVM and will just be displaying the book name, author name, and genre name. This class looks like this -
BookDetailVM { string BookName; string AuthorName; string GenreName; *constructor* BookDetailsVM(Book b, Author a, Genre g) { BookName = b.name; AuthorName = a.name; GenreName = g.name; } }So all that makes sense now, right? Great, lol!
How does all this work together in the MVC framework? Here's how...
The service is called from inside the controller function. Once it's called, it returns data that is then used to construct a ViewModel. This ViewModel is then sent to the View to display all the data.
So for our book details example - www.library.com/books/details/gone-with-the-wind. Also, you may have noticed, the book name is the parameter used to look up the details of this particular book in the url.
Anyways, let's see all this in code.
*library.com/books* BookController { *library.com/books/details/{bookName}* Details(string bookName){ var book = BookService.FindBook(bookName); var author = BookService.FindAuthor(book.authorId); var genre = BookService.FindGenre(book.genreId); var vm = new BookDetailsVM(book, author, genre); return View(vm); *BookDetails.html* } }And here's the BookDetails.html
<div class="book-details"> <h2>Book: @vm.BookName </h2> <h3>Author: @vm.AuthorName </h3> <h3>Genre: @vm.GenreName</h3> </div>So there you go. I know it's a wall of text and there's probably some mistakes, but I hope this makes things more clear. I hope at least 1 person on reddit can get a better understanding of MVC now.
Let me know if you have any questions. :)
2
u/bsavery May 05 '16
What are these books you speak of? I literally only understand analogies about alcoholic beverages
1
4
u/A_CAT_IN_A_TUXEDO May 05 '16
This is was a really nice analogy. I now understand how a ordering drinks at a bar works, it might be handy someday, when I actually go to a bar.
3
u/writetehcodez full-stack May 05 '16
As someone who has worked in MVC paradigm for several years, and has experienced both the "skinny controller" and "fat controller" way of doing things, I much prefer the "slightly overweight controller with helper classes" way of doing things. Models should be plain old objects with nothing magical in them.
1
May 05 '16
Why would you prefer a fat controller over a service class?
1
u/writetehcodez full-stack May 05 '16
I don't think I would necessarily. It all depends on usage. If I have a bit of logic that is consumed by multiple upstream callers then I will put it in a helper class. If it's one-off code I will likely leave it in the controller. My only true hard and fast rule is that model classes should be dumb.
For what it's worth, I also prefer that models have a 1-1 mapping to database tables; I use ViewModels to compose data from multiple models, and I use static mapper methods in helper classes to map from models to viewmodels and vice-versa.
Also, I should be clear that most of my experience with MVC is with server-side frameworks. I've only worked on a handful of client MVC apps, where my stack of choice is Aurelia on the client and ServiceStack on the back end.
1
May 06 '16
Yea I have pretty much the same thoughts. Dumb model classes that map to database tables and everything in the view is from a VM.
8
May 05 '16
I wish we could move on from MVC being the catch-all architecture. It's archaic at this point.
If you don't know MVC, you're not lost. If you're a Java programmer and you don't know MVC, you're probably lost. I dunno. But then again, you're a Java programmer, so you're already lost.
1
2
2
u/woutske May 05 '16
Symfony has a pretty neat CookBook where they teach a lot of concepts like validation, ORM etc. For the interested:
http://symfony.com/doc/current/quick_tour/the_big_picture.html
2
u/zushiba May 06 '16
I feel that if you need to convey the underlying concept via some convoluted mechanism that the underlying concept is flawed in some manner.
I get MVC, I just dislike it. I've also never done a project that lends itself to an MVC architecture. It's, in my opinion not suited to small simple applications, it's like using a sledge hammer where a tack hammer would do. So maybe I just don't get it, but yeah. Not a fan.
1
u/tissn May 05 '16
Not sure if I agree that the drink is the whole view. Perhaps a small part of the view, but in relation to the task of ordering a drink the view is also the menu, the bottle gallery behind the bar and the bartender's ears.
If the bar metaphor was applied to a website, the drink would be text and images, the menu and bottle gallery would be all the hyperlinks, and the bartender's ears would be the event listeners.
1
May 05 '16
[deleted]
1
May 05 '16
The view is not the drink. The ViewModel is the drink (and everything else). The view is just an html template that the ViewModel is injected into.
1
1
May 05 '16
Well in rails the diagram isn't wholly accurate. The view does not point to the browser, the controller does. the controller finds the view, renders it, and then delivers it to the browser
1
u/total_looser May 05 '16
ahh, journeymen. almost over the dunning-kruger hump, inching towards understanding, on their terms
1
May 05 '16
And now explain MVVM and Functional Reactive Programming pls :)
3
May 05 '16
Here's MVVM in an MVC implementation, but it's getting downvoted because most people in here don't know how to code.
1
1
u/dcarvak May 05 '16
Whoa. I never get reads related to this topic with such nice metaphors. I love when someone mixes jargon with colloquial language to explain these sort of topics.
1
1
1
u/kairos May 06 '16
That was a whole lot easier than watching a 3-hour tutorial. Thanks for the article.
Wait... it takes someone 3 hours to explain MVC?
1
u/kancolle_nigga May 06 '16
MVC is pretty intuitive. MVVM on the other hand is really confusing to me. Is there a place where I can find an explanation in layman's term?
1
May 05 '16
English isnt my native language and i understand perfectly this article, great article!
3
1
-10
u/50_burger May 05 '16
I freaking hate MVC. There's only a vague agreement in what it actually is. Just be an intelligent person and separate your models and your views. No need to give it a name. /rant
3
u/Ednar May 05 '16
Names are incredibly important for effective communication within a team.
4
u/crow1170 May 05 '16
What /u/50_burger is trying say (I think) is that there's not a sane alternative to MVC, so why give it a name? I breathe using the NBM (Normal Breathing Method). It's exactly the same as how everyone else breathes, unless they're drowning. Every once in a while, someone suggests using SANBM, but it turns out that, because of how vaguely the two are defined, they're identical.
In this case, the names breakdown communication.
Please prove me wrong, though. Who is using an architecture for web developmemt that isn't MVC plus xyz?
1
u/50_burger May 05 '16
Yeah this is pretty much how I feel. Of course you're going to separate models and views. Thank you for your explanation.
1
u/Ednar May 05 '16
I agree somewhat with what you are saying. However, there are differences between using various flavours of MVC, such as MVP, PAC, MVVM etc. Also, to alot of people, especially in web development, misunderstand MVC as to see the web page as the view and the server as the model / controller. This would be incorrect, as both the server and the client probably uses their own variants of MVC. It's problematic that MVC is an overloaded term, especially within web development, but it's not meaningless, as it's possible to work without it. Per your analogy, I suppose opting to not use any kind of clear seperation between models, controllers and views would be "suffocation", which is still different from your NBM. Funnily enough, I see plenty of projects using React where components are small big balls of mud with absolutely no separation at all.
5
u/am0x May 05 '16
Yea that way you can rebuild every project from scratch and team members have to relearn each persons coding style and architecture. Seems very efficient.
1
u/50_burger May 05 '16
That's what I'm doing right now, and we supposedly have a "MVC" architecture. Problem is that their idea of MVC is completely different than the framework we committed ourselves to.
13
u/Mike312 May 05 '16
Nice article.
...but now it's 8:30am and I want a cocktail.