I was browsing the MVC forum on the ASP.NET site and found a topic asking about MVC training. Since the Microsoft ASP.NET MVC framework has not been released yet, you would be hard pressed to find a training class dedicated toward their framework. MVC is not new, though. There are other classes out there that may not target an actual implementation or they'll target existing implementations (MonoRail, Spring, Structs).

Beyond that, though, I found this post pretty interesting:

 in my opinion it´s not so complex as ASP.NET WebForms (because no ViewState and no Postback - its just a ping pong with the view and the controller ;) (and the model ;) )).

He's right. ASP.NET MVC does not have such complex areas as ViewState. You just write a controller, write a method that becomes an action, create and edit your view, and then hook them up. Pretty simple, right? Maybe.

ASP.NET WebForms - What was the goal?

The WebForms project model tries hard to be developer friendly. It takes HTTP and tries to tuck it away. Instead of worrying about a stateless envrionment, WebForms makes the developer believe that it is quite stateful. ViewState, for example, can help you store state. Even the controls that render simple HTML can remember their values. WebForms, in a basic view, is Windows Forms for the web. You have state, controls and even an event lifecycle for a page. Theoretically, Windows Forms developers should be able to migrate to web projects and see some familiar areas. All is good in the world.

WebForms Can Be Sneaky

After a while, though, that great feeling starts to go away for many developers. ViewState becomes awkward. The controls don't generate the HTML that I want it to. I can't seem to test my pages in a non-awkward way. In the end, the WebForms abstraction has become more complicated than the entity that was being hidden. For some developers, the WebForms model works. If it works for you, then great, continue to use it. If not, Microsoft has heard your call.

Welcome, ASP.NET MVC

First off, MVC is not some new thing Microsoft invented. Yes, they created their own MVC framework, but they didn't create the concept. ASP.NET MVC isn't even the first framework for .NET. MonoRail, another MVC .NET implementation, has been around for quite some time. 

The MVC pattern separates the application into three layers: model, view, and controller.  The model is your domain model. If you were developing a store, you would probably have models representing an order, customer and a product. The view is your user-interface. This is what your end-user will see. In a web application, your view typically contains HTML. A controller is typically a class that controls the interaction between the model and the view. Once a controller action has been called, it has logic in place that ties both the model and view together. 

Separation of Concerns

The MVC model promotes separation of concerns (SoC). Your model contains the business logic, not presentation logic. Your view should contain presentation logic, not business logic. Why did I say should? Well, it's up to the developer.

Learning How to Use MVC Correctly is the Most Difficult Part

The framework itself is not hard. Learning how to use a framework properly is hard. Anybody can create a controller, add an action, and then throw text onto a view. Learning how to do that the correct way will take time, though. Sure, you could migrate your WebForms application and place your Page_Load event in an action, create better URLs and call it complete. What are you really buying yourself, though? If you have business logic in your controller, the Single Responsibility principle is now broken because the controller is doing 20 different things. In the end, the only thing you've done is migrated from one framework to another and lost a few features you didn't like. That's it. You can't fully harness the testability features of MVC.

Update your Bookshelf or Get to Class

The best thing you can do is learn software design techniques that are not tied into a specific technology.  Take a class on software design, buy a book on software design, read about design patterns and when to use them. Learn about and practice Test-Driven design. There are so many options.