Thatsa tasty design pattern

Last Thursday morning I was on the train coming into the city and I was rehearsing my presentation on ASP.NET MVC. This works out well because I travel for an hour each way (each day) and the time allowed for my presentation was an hour.

I'd been rehearsing for days now and I still felt that something was missing. I needed a clear and simple way to express the relationships between all of the moving parts. There must be a clear analogy, something that people would be familiar with, something not involving the actual technology. After all, design patterns aren't about .NET or Ruby.

Around Claisebrook I thought of the Pizza Shop Example and hurriedly dropped it into the presentation during my lunch-break. It seemed to be a success that night when I gave the presentation and quite a few people commented afterward that they liked it.

I'm sure I am not the first to come up with analogy but for those who weren't there, here is the MVC Pizza Shop story.

Mark, Vinnie and Carmella run a pizza store. When you ring the store, Carmella answers the phone and takes your order. Perhaps you tell her, "Just give me the usual", or maybe you say, "I'll have today's special". Maybe you are picky about your pizza and give her a complete list of ingredients.

You're going to tell her where you'd like it delivered (your address) or, if you are a regular, she might have your details on file. Once you've given her all the information she needs to get you your pizza, she hangs up.

Carmella takes your pizza order into the kitchen and hands it over to Mark. Mark isn't great with people, he'd prefer to stay in the kitchen all day and make great pizza. He might understand if Carmella tells his to make "The Special" or she might just translate that into a list of ingredients. Either way, Mark will provide Carmella with the pizza that she asks for (on behalf of you, the customer).

Once Carmella has the pizza order and the address she heads into the front of the shop and hands it over to Vinnie. Vinnie loves his car and zips the piping hot delicious pizza straight over to you. On the way he rehearses the speech he likes to give to customers.

In the context of the above story we have:

  • You, the customer (User): Note that you gave your request to Carmella but received the response from Vinnie. You have no details on how the pizza was made as you never come into contact with Mark
  • Mark, the pizza chef (Model): Mark knows to make great pizza but knows nothing about customers. He never takes an order from a customer and he never gives a pizza to a customer. Carmella could be making orders up and Vinnie might be dumping them in the trash or eating them himself. Mark doesn't care. He just makes great pizza.
  • Vinnie, the delivery guy (View): Vinnie can't make a pizza to save himself and he forgets orders all the time but he loves to drive and he can follow directions fairly well. Nobody delivers a pizza quite so well as Vinnie.
  • Carmella, the manager (Controller): Carmella is great with people, customers and staff alike. She can't cook and doesn't have her licence, but she does have strong organizational skills.

I hope you can see the Model-View-Controller pattern coming together in the MVC Pizza Shop. Going the other way: The User (you) makes a request of the Controller (Carmella) who interacts with the Model (Mark) to fulfil the request and gather any components which need to be returned to the User. Once completed the Controller takes any presentation objects (Pizza and Address) and hands them to the View (Vinnie) for delivery.

The example easily extends to show what I think is one of the more important aspects of using MVC, loose coupling. Let's say that you don't ring the store. Instead you walk in off of the street. In that case you might speak to Chris (another Controller) who will take your order, translate it for Mark, receive pizza back from Mark and put in on the counter-top (another form of view, albeit a simple one).

Or maybe the MVC Pizza shop takes orders via SMS. Or email. Or however. In each instance, the shop needs a new controller but the Model and View components may remain the same. You can swap out any component in the process easily without affecting the rest.

Some more examples include:

  1. Getting Marks wife Maria to come in when it gets busy and re-heat pizzas that Mark made earlier that day. (The customer doesn't know how their pizza gets made). [Model]
  2. Buying the new Vanisher3000 instantaneous transportation system. When the pizza is ready the Controller just drops the pizza in and feeds in the address. The Vanisher3000 atomizes the pizza and rematerializes it at the customers kitchen table (Freshly rematerialized pizza is the best). [View]

If ever you've worked in a pizza shop, you probably already gave up on this analogy a while ago saying, "But it doesn't work like that, everybody does everything". This is true of most pizza places I've ever been in but it is probably the biggest source of lost orders, incorrectly made (or sliced) pizzas, the right pizza being delivered to the wrong house and so on. Well-run places will assign people to a single job per shift (and expect them to help out others only if they aren't busy).

I hope this has helped to clarify the MVC Design Pattern for you. It can be confusing when first you see it but it seems much easier to deal with when you can relate it to real-life, every-day occurrences. If you have any queries about the analogy please comment on the post.

mvc3design-patterns
Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History

Comments

No comments yet. Be the first!

No new comments are allowed on this post.