ASP.NET MVC Diary #1 WHY?

So I decided to take the ASP.NET MVC plunge recently by signing up to do a local user group presentation. I knew this would force me to put in the time and would help the ramp up. As developers, it's easy to stay in our comfort zone on the technologies we already know. It's easy to get left behind with all of the mirage of products coming from Microsoft like Visual Studio 2008, .NET Framework 3.5, LINQ, WCF, WPF, and now ASP.NET Model View Controller (MVC).

Here was my approach to learning the ASP.NET MVC:

First, WHY? Before investing a ton of time, I want to know why I would use this in the real world of consulting. The clients we serve should receive quality products in the most efficient way possible. I have used the design architecture pattens Model-View-Conroller (MVC) and Model-View-Presenter (MVP) some in the past so I was familiar with the concepts. Here is what I gathered from my research:

• Separation of Concerns - It’s easy to fall into the trap putting most of the code in the presentation layer. Project timelines and the lack of design time can force us to develop web applications that will be sufficient for the client and will probably work well for years. On a project per project basis, there is no clear benefit on using something like the MVC pattern. However, when we look at the project portfolio code reusability, testing, and separation of concerns is accentuated. With MVC, the interface can be refactored without impacting the data and model layers. Vice versa, the data and model layer can be refactored without affecting the interface. Sure, we can code this without the ASP.NET MVC framework, but it takes a ton of coding, time, and design efforts. ASP.NET MVC framework is far superior when considering value added.


• Testing - Now that the program boasts true separation of concerns, it's naturally easier to test each layer independently. Additionally, the buzz word "TDD" or test driven development can implemented as well.


• Reusability - Again, on a per project basis it's sometimes hard to sell this becuase it's hard to realize the immediate value added. Unless we look at the total project portfolio, we cannot see the benefit. For example, lets say you are working on a web application that looks up customers. You build this using the ASP.NET MVC with clear separation of concerns implemented. Two more projects are slated for release later that year: PDA Customer lookup and KIOSK Customer Lookup. The model and controller can be reused and only the views need to be implemented. In the past, it's been easy to do this by "cloning" the whole application and changing the HTML and code-behind pages. Next year, version 2 needs to be rolled out and now you will have to change three versions of all three layers. Clearly, the MVC is far superior.


• Intuitive URLs - Arguably, this reason is as compelling as it's MVC architectural pattern. The ASP.NET MVC uses REST architectual pattern. With MVC, the URL is abstract and does not directly map to a web page address like classic ASP.NET does. So myapp/customers/Brown is much cleaner and superior to myapp/customers.aspx?name=Brown. So what? Well, now the URL can map to multiple views where before you had to use query string paramteters to figure out the logic. Additionally, now you can switch out the the views and not remap URLs. More on REST on my next Diary - #2 What?

Ok, now that I have convinced myself that this seems (and I stress "seems") to be very valuable, the next step is to download and explore the WHAT.