I wouldn't normally consider myself an early adopter. In fact, I prefer the 'tried and true' to the 'hip and new', especially when it comes to software development. However, that doesn't mean I should keep my head in the sand. While I might not always live on the bleeding edge of .NET development, I should definitely be aware of what's going on there. With that goal in mind, I'm going to dedicate a series of posts specifically to looking at the new ASP.NET MVC framework.
ASP.NET MVC was introduced last October at the ALT.NET conference and Preview 3 is readily available for download here. It's still in the pre-release phase, but with all the hype surrounding it I can't help but feel like I'm already having to play catch-up. Lucky for me there are many great blog posts, articles, and video tutorials readily available to aide in my quest to become a master of everything MVC. So follow along as I start with the basics of MVC and then go wherever the code takes me.
By way of an introduction to this new series, I think it is useful to examine the ASP.NET MVC framework at a high level and take a look at what it is trying to do. Let's first take a look at the MVC design pattern it is based on and why we would want to use such a pattern in the first place, then examine what we are going to get from the ASP.NET implementation of the pattern.
MVC, the Pattern
The Model-View-Controller pattern was described almost 3 decades ago by computer scientist Trygve Reenskaug. At its core, the MVC pattern describes a way for developers to isolate the user interface of an application from its domain logic, making each independent of the other. This separation of concerns takes me back to the days of Computer Science 101 where we learned that modular programming allows developers to more easily maintain applications by separating the application into distinct functional units. We can then easily change the implementation of one unit without having to make changes to every part of the application. This is the goal of MVC.
In MVC there are three units: the model, view and controller. The model represents the data on which the application operates: it encapsulates the data layer of the application and provides domain-specific logic to give the data meaning. The view is generated based on the state of the model and acts as the user's interface to the application. And finally, the controller handles events from the user interface (user input), notifies the model of such events (which may change the state of the model), and notifies the view when the model has been changed.
ASP.NET MVC, the Framework
I'm going to leave the "how" of Microsoft's implementation of the MVC pattern for another post, and instead talk now about what you can expect from the new ASP.NET MVC framework. For starters it is built on top of ASP.NET so you continue to have access to all the wonderful goodness provided therein (membership/roles, caching, health monitoring, etc). It is highly pluggable, so if you don't like how the framework implements something, you aren't stuck with it. In addition, you can expect to be able to create web applications that are much more easily testable than the current Web Forms model. In fact, Test Driven Development is a key goal of the framework, as is evident by the fact that you are asked to create a test project when you create an ASP.NET MVC project in Visual Studio. And since all of the core contracts in the framework are interface-based, testing is even easier as you can mock out dependencies and focus on the specific component being testing.
One big question that is often asked is: will ASP.NET MVC replace Web Forms? Simply put, no. Microsoft has been very clear that this is only an alternative to Web Forms and should not be interpreted as anything else. ASP.NET has long been one of the few web development frameworks without support built-in for MVC, and some developers prefer this kind of framework to the complexities involved in managing the state of a web form in ASP.NET.
So the next question asked would probably be: when would I use ASP.NET MVC instead of the traditional Web Forms? The answer to that is less straight-forward, and quite frankly depends on what you are trying to accomplish. ASP.NET MVC is very different from the traditional Web Forms/post-back style of development we are used to with ASP.NET. I challenge you to follow along with me as I learn how to use it, then go take a look at it for yourself to decide if it's something you can use for your own projects.
Since I, like you, am a mere traveler on this road towards ASP.NET MVC enlightenment, I'd like to share with you the resources I used to aide me on my journey. I'll include them at the end of each post so that you can further study the topic for yourself and (hopefully) gain a deeper understanding of the topics discussed.