Another way to think about MVC, many said this analogy helps

This post about MVC concepts using a simple analogy has been edited a few times over the years. It is intended for those who are starting to grasp the basics of the MVC paradigm, but are having a bit of a hard time understanding some of the rules and concepts.

We’ll use this interesting analogy that I thought works quite well to further clarify some things…

So, let’s imagine a bank.

The safe is the Database this is where all the most important goodies are stored, and are nicely protected from the outside world.

Then we have the bankers or in programmatic terms the Models. The bankers are the only ones who have access to the safe (the DB). They are generally fat, old and lazy, which follows quite nicely with one of the rules of MVC: *fat models, skinny controllers*. We’ll see why and how this analogy applies a little later.

Now we’ve got our average bank workers, the gophers, the runners, the Controllers. Controllers or gophers do all the running around, that’s why they have to be fit and skinny. They take the loot or the information from the bankers (the Models) and bring it to the bank customers the Views.

The bankers (Models) have been at the job for a while, therefore they make all the important decisions. Which brings us to another rule of MVC: *keep as much business logic in the model layer as possible*. The controllers, our average workers, should not be making any important decisions, they ask the banker for details, get the info, and pass it on to the customer (the View).

Hence, we continue to follow the rule of *fat models, skinny controllers*. The gophers do not make critical decisions about the flow of the business logic, but they cannot be plain dumb (thus a little business logic in the controller is OK). However, as soon as the gopher begins to think too much the banker gets upset and your bank (or you app) goes out of business. So again, in MVC terms, always remember to offload as much business logic (or decision making) to the Model layer.

Please note, that many times stuffing more code into a single User.php file may not be the best idea, therefore most framework allow to extend (but more importantly separate) basic functionally that may be needed by one or more models into “services”, “behaviors” or simply additional libraries which are used in your models.

Now, the bankers sure as hell aren’t going to talk to the customers (the View) directly, they are way too important in their cushy chairs for that. Thus another rule of MVC is followed: Models should not talk to Views. This communication between the banker and the customer (the Model and the View) is always handled by the gopher (the Controller).
(Yes, there are some exception to this rule for super VIP customers, but let’s stick to basics for the time being).

It also happens that a single worker (Controller) has to get information from more than one banker, and that’s perfectly acceptable. However, if the bankers are related (otherwise how else would they land such nice jobs?)… the bankers (Models) will communicate with each other first, and then pass cumulative information to their gopher, who will happily deliver it to the customer (View). So here’s another MVC rule: Related models provide information to the controller via their association (relation). In plain SQL terms you’d achieve the same effect by JOIN’ing tables with relevant information. With MVC frameworks we typically rely on the power of ORM.

In our bank it would look something like this:
Worker Andy -> asks banker Bob Buzzkillington -> who asks another banker Jim Buzzdickenson -> who gets the loot from the safe (the DB).

In CakePHP framework terms it looks very similar:
$andysInfo = $this->Bob->Jim->grabMeSomeLoot();

So what about our customer (the View)? Well, banks do make mistakes and the customer should be smart enough to balance their own account and make some decisions. In MVC terms we get another simple rule: it’s quite alright for the views to contain some logic, which deals with the view or presentation. Following our analogy, the customer will make sure not to forget to wear pants while they go to the bank, but they are not going to tell the bankers how to process the transactions.

Well, that about covers most of the basics. I hope this analogy helps somebody rather than confuses them even further…

Let’s just summarize some of the MVC rules and concepts:

  1. Fat models, skinny controllers!
  2. Keep as much business logic in the model as possible.
  3. If you see your controller getting “fat”, consider offloading some of the logic to the relevant model (or else bad things will start happening!).
  4. Models should not talk to the views directly (and vice versa).
  5. Related models provide information to the controller via their association (relation).
  6. It’s quite alright for the views to contain some logic, which deals with the view or presentation.

P.S. Any suggestions on clarifications or additions to this little article are welcomed as always.

Also published on Medium.


    Nicely done, Teknoid! I enjoyed that analogy. It’s most likely due to the fact that I work in the banking industry and have been working over the past 2 years exclusively on a banking application written in CakePHP. With that said, I can neither confirm nor deny that any of our clients are “fat, old and lazy” :P


    LOL, well I’m glad you’ve enjoyed it.
    I must have been a little… oh… “out of it”, when I decided to write this up :)

  • I loved this. Great analogies!

  • @Steve

    Thank you.

  • Adam

    Nice post Teknoid, I enjoyed reading this.

    However I think the analogy makes more sense if you actually understand MVC already, which is unfortunately often the case with such analogies! I would be interested to know if anyone not familiar with MVC found this explanation helpful.

    After doing security-analysis on a non-cake php app today, I can confirm there are still people who don’t understand the importance of decoupling / MVC, so I hope your post helps those people and I can stop having these WTF moments while reading other people’s code.

  • I like it, can I make a translation(romanian) and put it on my blog, specifing who’s the author?

  • Pingback: CakePHP : signets remarquables du 06/01/2009 au 07/01/2009 | Cherry on the...()

  • @Adam

    You might be right, unfortunately there is no way for me to tell if this is actually helpful or just a bunch of weird gibberish :) Hopefully at least the summary of rules will put someone on the right path of thinking about MVC.


    Absolutely, no need to ask even… I don’t believe in copyrights and all that nonsense (of course a little link back would be nice :))

  • Creative Commons Attribution License! :) I think WordPress has a plugin that allows you to add a CC license, and considering how much useful information you have on this blog for CakePHP users, I think requesting a link back for those that wish to use your information to be a good thing.

    Ok, back to the topic at hand. I have a question over a situation I have with one of my apps that if given the chance, I’ll do over again completely from scratch (leaving only the database and data intact). It was my first CakePHP project afterall.

    It’s a voting/ranking application. Once per week, one registered user may vote on a set of options. On the “add vote” page, there are the same number of dropdown boxes as optional votes for the week, all set in an ordered list. So, assuming there are 10 items to vote on in the database, the first dropdown box will assign 10 points to that item, the second dropdown in the list will assign it 9 points, and so on, accumulating points to create a ranking system.

    The problem is that once the system has points in the database, a business rule is activated. No item can be voted +/-2 ranks from its position the week before. As this is business logic, I feel it should be handled by “the banker”, but at the same time, that means there’d be N number of requests to the database in order to create the lists, rather than a single query to access the current ranking order, and let PHP do the work in the view (which is what I’m doing now). But, the controller, from what I understood, should be what smooths over the data for the view, simply passing data values, but primarily simple modifications. I’m accessing a global variable for the rule CONST number being passed in from the controller (+/- *2*), and…well, I don’t know.

    The more I think about this specific situation, the more I get confused as to where it should be. :)

  • I meant to mention that my question actually did have something to do with this blog post, and with MVC. :P Just thought I’d clarify.

  • Beth

    Now I get it ;) Just joking. Fantastic analogy. I always wanted to become a banker but unfortunately, I’m only a gopher!

  • @Beth

    Ohh… I hope you get through this tough line of work :)


    I honestly tried to figure out your issue, but the holiday season (aka vodka) had slowed me down just a little bit… hopefully I’ll (or somebody more responsible) will have an answer soon… ish…

  • Pingback: links for 2009-01-07 « Richard@Home()

  • I like it too, I think the same concept can be applied to other type of business too, but with bank you hit the target :D

  • @Nik Chankov

    Thanks ;)

  • Pingback: Another way to think about MVC « Topstr()

  • I would like to disagree about view not talking to model directly however vice versa should never happen – it is a MVC vs. MVP thing

  • @Tarique Sani

    Well, I would hate the break the analogy there :) Plus we’d agree that on a basic level it’s better that controllers handle the “communication”.

    Completely unrelated, could you shoot me an email? I have some potential projects that I may need to “offload” very soon to a trustworthy bunch of CakePHP devs. I know that you guys have been around for a while, so I was hoping you’d have some room for extra work (all paid).

  • Haha, great lens to apply to MVC. I am going to share this with an old professor of mine who teaches a few classes surrounding MVC patterns.

  • @Edward Webb

    Thank you. Didn’t even know that there are actually classes that deal with MVC concepts.
    Good stuff, glad you’ve enjoyed it.

  • Ryan

    Great post! This analogy is leading me to believe I have obese controllers and anorexic models. Probably not a good thing. This led me to post a question on Stack Overflow in order to learn and improve my code in this area. The link is if anyone is interested in chiming in.

  • @Ryan

    Thanks, I’m glad you’ve enjoyed it.

    I tried to give you some answers, the best I could…
    Here’s a somewhat unrelated post, but I figured I’d share since it does talk about an important issue… and covers MVC a little towards the end, as well:

  • Ryan

    @teknoid: Thanks for the reply here and on Stack Overflow.

    I feel like I have the concept straight now, but I’m still pretty shaky on the execution. In moving logic from controllers to models, I’ll be relying heavily on model callback methods and custom model methods, correct?

    Only two pages in the Cookbook dedicated to this:

    And of the numerous Cake tutorials I’ve looked at, I can’t recall one that uses these. If you’re considering topics for upcoming blog posts, I’d love to see some material on writing methods for your models.

  • @Ryan

    No problemo.

    Yes, the model callbacks like afterFind() and beforeSave() is where you’d like to move some/most of the logic.
    As far as writing your own methods, it is not different than simply wrapping some logic inside a good ol’ function(). Actually if you search around the blog, I have quite a few posts that directly or indirectly show how to deal with model methods.
    Plus, don’t be afraid to take at the cake core, you can learn quite a bit ;)


  • Ryan

    @teknoid: Will do! And FYI, I subscribed to this thread but didn’t receive any of the email notifications (in my inbox or spam filter).

  • @Ryan

    Hmm… well, gotta talk to wordpress about that one. I haven’t done anything specific to disable that…

  • Ryan

    Go figure… I got the notification this time!

  • @teknoid: I just realized…my specific business logic belongs be in the view in this paradigm, but if I have repetitive business logic it should be separated in to a Helper. It just randomly dawned on me, figured I’d post back. Such a simple solution too. :P

  • @Brendon Kozlowski

    Well, good to know you’ve got it figured out ;)

  • Pingback: What is Kohana? | PhpMen()

  • I am a beginner in the CakePHP MVC framework. Your analogy has helped with the headaches I have had learning MVC. But, what do you suggest for the learning curve of having to know linux / unix commands? I seem to get stuck there (as I haven’t gone through computer science yet in the university), and pay the other guys to do that stuff on our server…


    Filling in the knowledge gaps while trying to build a business.

  • @Jared

    IMO, the system administration world is changing… with new cloud services available from many vendors, your tasks as sys admin really diminish.
    “Everything” comes pre-installed, firewalls are fully manged, you don’t need to worry about system resources with burst-able setups. Even load balancing and content delivery networks are ready to work out-of-the-box (with services like CloudFront).
    It’s important to pick the direction of what exactly you’d like to learn, for basic unix commands there are countless google results that will answer almost any question, or, of course, you can go an old-fashioned way and buy a book ;)

  • Daniel

    What an excellent anology! Think this has finally got the concept straight in my head, now off to try find some example implementations. Thanks!

  • @Daniel

    Glad you’ve found it helpful. Cheers.

  • Pingback: Using the Model-ViewController Architecture « SPICY!()

  • Pingback: Use the Model-View-Controller Architecture to Supercharge Your Web Development | Ooh...Spicy!()

  • CConnor

    Really helped me grasp MVC concept a bit better!


  • sipiatti

    Thanks for make me understanding this concept better!

  • @sipiatti, CConnor

    Glad it helped.

  • Hemant Pancholi

    I must say, Very nice anology, having good example relate to real world with MVC.

  • @Hemant Pancholi

    Thank you ;)

  • Kavya K.R

    Wow I love this article… I finally understood about MVC… Thanks a ton!

  • Pingback: Organic Programming » What is wrong with MVC?()

  • RSK

    i feel ashamed that i didn’t saw this post before.
    even though i visited your website for many hacks.
    Any way thankz for the nice explanation with the best example.
    Form the next piece of code i will try my best to keep my “models FAT and Controllers skinny” ;-)

  • teknoid


    That’s very important.
    Especially because models are much easier to test, so the less logic you have in your controller, the better off you are in the long run.

  • Aziz

    Happy new year teknoid. This was a good reading to start off the new year! For some reason controllers get all the attention, since they are skinny. The fat models are always ignored.

  • Rishish

    Very help full,It remind me the days of my college how professors relate the concepts with stories and explain us.

    Many Thanks

  • ignotus

    Nice analogies. I knew about skinny controllers and fat models but this sounds a good way to explain it. I always had difficulty making people understand why controllers should be skinny and models fat. This post is really helpful.
    Thanks teknoid… :)

  • It’s really a nice post.It gives me some insight about MVC.
    Hope that more articles on cake PHP frm ur side.

  • Pingback: 5 resources to start your ASP.NET MVC3 journey » Wazoo Enterprises Inc.()

  • teknoid


    Thanks for all the positive feedback.
    I’m really glad to hear that it has helped quite a few people to “get down” with MVC.
    After all, it is a great concept and has helped us (developers) to get things done better and faster and most importantly keep everything much more organized and manageable.

  • Wondering if we can expand the analogy a little. What would you think of adding bank tellers to the Views? The tellers greet incoming customers & figure out their request ( the user input ). We don’t want our tellers disappearing into the back to pass off information, so they talk with the gophers, who pass off the request to a manager or banker ( depending on the type of request ).

    While that’s going on the teller stays at the front and keeps interacting with the customer to make sure they don’t get bored/confused and walk way. The gopher gets the loot from the bankers or gets applications ( say for a loan ) from the managers and hands it off to the teller who updates the customer with the new info. In other words, the Views aren’t the users/customers, they’re the ones who deal with the users/customers.


  • teknoid

    @Adam Pieniazek

    Sounds pretty good. In general I would say that tellers would be more like “Helpers” (in CakePHP terms)… Views do not pass back the info, but in rare cases like requestAction() they can request it.

    Overall you can sub the view analogy to play the “teller” role… Nothing wrong with that.

  • Kirikamal

    Hi Teknoid,

    Greate article…..tahnk u very much

  • Pingback: Never Call find() from a Controller « Off The Self()

  • (bs.)

    You must know that you have started something pretty phenominal here. There are questions all over the programming Internet community asking for analogies, or layman terms, to MVC and ALL of the great answers link back to your “Bank Analogy”.

    Way to go, this was incredibly helpful for me.

  • teknoid


    Thank you. Glad that people are finding it helpful.

  • Awesome Article,
    Thanks for sharing
    Keep it up

  • Woody_1983

    Great piece, clear and easy to understand.

  • Etienne

    Probably the… best explanation or analogy I’ve found on the subject :)
    Good job – for real.

  • Pingback: Tutorial 1: Installation, Setup and "Hello World" - Leon RowlandLeon Rowland()

  • Pingback: Another way to think about MVC | nuts and bolts of cakephp | Thoughts And Ideas()

  • Pingback: Understanding MVC model in Cakephp Context | Thoughts And Ideas()

  • Josue Montano

    Great example!!! I’ll never have to check Head first design book again

  • awesomethriller

    Well, this is the best article concerning MVC Pattern that I’ve stumbled upon so far! Thank you so much!

    • teknoid_cakephp

      Thanks. Glad that people are enjoying it after such a while :)

  • Nice article. I came across another great analogy recently that compared Model / View / Controller to VCR / TV / Remote control. Both were really helpful to me.

  • john

    Well done.

  • Ashwani

    can I know about those VIP’s please..

  • Mwas

    Thank you for this article and all your articles.

  • nitin

    thanks a lot.great article on mvc.

  • Pingback: Helping others to understand coding | Rails Girls Berlin()

%d bloggers like this: