<p>I have seen the ASP.NET community buzzing about MVC. I know the basics of its origin, and that there are many sites (unless I am mistaken, stack overflow itself) based on ASP.NET MVC.  </p>

<p>From everything I have heard and read about MVC it seems to be the future of ASP.NET development. But since I don't usually dabble in .NET web development I am left wondering the following: when is it appropriate to use MVC and when is it not, and why? Examples of great (and terrible) use of MVC would be fascinating.<br>
Though I realize there are other implementations of MVC view other languages like RoR I am more interested on its impact for .NET programmers.  </p>

<p>If this has already been gone over, my apologies! </p>

Here are my 2 cents about MVC for web applications.  For the sort of GUI apps for which MVC was originally intended, "listener" code was required, so that the UI could be updated when events altered the model data.
In MVC for the web this is unnecessary, you get your listener for free: the web server, and the HTTP request IS the event.  So really MVC for the web should be even simpler.  Indeed, it could be boiled down to the Mediator pattern, where the Controller mediates between the model and the view.
There are two things that there is a lot of confusion about.  Regardless of conventional "wisdom":
Frameworks != MVC
Database Data != "Model"
"Full stack" web development frameworks typically add lots of features, and may or may not be MVC-oriented at their core.  One of the features many frameworks add is database access or object relational mapping functionality, and because frameworks and MVC get confused, subsequently database data and the model facet of MVC also get confused.  The model can generally be viewed as the underlying data for the application, but it does NOT have to come from a database.  A good example might be a wiki, where the underlying model/data consists of file revision data, for instance, from RCS.
Hope this helps and I'm sure others will have plenty to add.