In the beginning, there was Input-Process-Output. Everything since then is just more details.
That's literally true. The original computer, Eniac, input data about artillery, processed it, and spit out gunnery tables. But they soon learned that it could do so much more. They used it for computations necessary to create the first Hydrogen Bomb. (What would we do without war to underwrite invention?)
The way to understand MVC is to realize that it's just the latest detail on Input-Process-Output. Except that now, it's called Model-View-Controller. Model is Input, View is the Output, and Controller is Process. Sort of. Most authorities recommend that you put your "process" in "Model" and let "Controller" simply act as a switching function. But we're getting ahead of ourselves.
Although I'll be covering the same ground again, I've written several short articles about MVC:
Sorting Through the New Toys - MVC (April 28, 2010)
MVVM - A Fad or The Future? (May 27, 2010)
My new book, Pro ASP.NET 4 in VB 2010 also has a chapter about MVC where much more advanced concepts are explained, such as using MVC to create web pages based on an Entity Data Model generated from a database.
If you're a VB.NET programmer (and I assume that you are), then you now have your mind wrapped around something called the "event driven model". Just like MVC, programming this model depends on having a clear mental image of what the software does automatically and what you have to add. The key to doing MVC is to shift gears to a different mental image. So, let's consider event driven programming for just a second so we can contrast it with MVC.
When you write the standard "Hello World" program using event driven programming, you typically put a Button and a Label on a Form. When the Button is clicked, .NET creates an "event" called the "click event". Your task as a programmer is to anticipate that event and write the code that inserts a String into the Text property of a Label control.
Public Class Form1
Private Sub Button1_Click(
ByVal sender As System.Object,
ByVal e As System.EventArgs
) Handles Button1.Click
Label1.Text = "Hello World"
End Sub
End Class
The key here is that nothing works unless .NET generates that magical "event" that triggers the execution of your code. MVC is like that. You anticipate things that MVC does and then just insert your code into the right places to make the resulting system do what you want it to do. But you don't code for "events" anymore. (Well ... you can. But then you're working in parallel with MVC. MVC will allow you to insert event driven programming. But that works "on top of MVC" rather than being part of it. When learning MVC, the first thing to do is banish event driven programming from your mind.)
That's why the three circle diagram of MVC is used so much. (I've illustrated the first article linked above with the standard version.) Those three circles are the part that happens "automagically" and where you need to think about putting your code. Unfortunately, it's nowhere near as simple as Windows Forms, as we will see.
To see what the difference is, we're going to code a "Hello World" app using MVC from the ground up. That last part is important. Nearly every other example you will see on the web starts with a runable MVC shell app that is just modified. On the next page, we code an MVC app using the empty app template and add everything we need manually so you can understand what's there and why.
