The list of questions in part one, New Frameworks Are Scary! An Elitist’s Tale, is my own. These are what kept me safe at night from the MVC monster under my bed, and these are why I hesitated about making a change, while convincing myself it was only because it would cut down on productivity and legacy application support.
Time to burst that bubble. Let's address my concerns:
"Didn't we try this with classic ASP?"
The web was never meant to have a state. As much as we like to fake state with (cringe) huge (or even deflated) session variable objects and session states, it's all a fake. At the end of the day, Web Forms outputs HTML just like MVC, just like PHP, classic ASP, andyou with Notepad for five minutes. Until we dig a bit deeper, we can't understand why MVC, with its Razor syntax, isn't just classic ASP with intellisense. So let's dig...
"Who is going to judge me when they see all this spaghetti Razor code?"
No one! Because you don't have to show anyone your first attempts! Drop $20 and invest in a domain and some cheap hosting, and get started (you can do it locally, but it isn't as fun if you can't publish it somewhere). Build a forum from scratch, a blog from scratch, a calculator application, anything. Get the feeling of using Razor, then worry about how to write clean Razor.
"What is with all these helpers?"
"What about security?"
This is definitely a hurdle you need to jump before you get into any production coding. There are some really good blogs about security issues in MVC that explain XSS and CSRF attacks. I won't go into the details of these, and don't make me Google it for you. Ok, to get you on the right track, his stack overflow post is a really nice place to get started.
"But I just spent 1/5 of my life wrapping my head around Web Forms and the Page Life Cycle!"
Get over it. You spent 1/5 of your life learning colors and letters when you were in kindergarten.
"Where does my business logic go?"
Unfortunately, I'm still young in my experience with MVC to experience the qualia of the separation of business logic between the controller and the business objects themselves. One blaring detail that I did not understand for the longest time and that you should take away from this if nothing else is: you can't use business objects as models. If you are developing an application with business logic, call it MVC+B if you need to.
In other words, you are working in a Model-View-Controller pattern for the web site, and if you have business logic in a web application, you need business objects that are separate from your models, views and controllers. The training wheels that I have chosen for myself until I get a better feel for separation of business objects to models is this: I will only use value types and strings in my model, and I will create my model around what I need to present on my view. Anything else that is needed by business logic goes in the business object.
"Name something I couldn't do with web forms in one tenth of the time it would take me to learn and write elegant code in MVC."
By now we all know that if you fall behind in this industry, you will flounder and eventually you won't be able to get a job. If you are not lucky enough to work for a company that gives its employees a day of professional development time or if you feel there is no hope for progression within your organization, then practice new stuff on your own time with one hand while surfing monster with the other.
"Why can't I just find ONE blog that tells me how to organize this crap?"
This one I couldn't really answer, so that's why I decided to write this blog.
For those of you who have far more experience than I do with ASP.NET MVC3, I should make a couple points to preserve my pride (told you, I'm elitist). There are concepts about ASP.NET MVC from its early versions through its evolution to MVC3 (and MVC4 beta, at the time of writing this) that I have purposefully left out of this blog simplicity's sake, among other reasons (so that no one is tempted to not use the Razor view engine while working with MVC3 - why, oh why, would you do that?). My goal was to avoid too much cross-referencing and information overload and to evoke the feelings of excitement that we all got when we made our first HTML page when we were twelve.
I hope this helps ease some of the tension some of you have with ASP.NET MVC. Don't forget to learn something new every day!
[Contributed by Tony Mayes, Interactive Developer]