Sunday, August 31, 2008

ASP.NET MVC Diary #2 WHAT?

Second, WHAT is the ASP.NET MVC framework?

Before diving into Microsoft's MVC, I decided to do a refresher recap of what the Model-View-Controller Design Pattern is. The design pattern was created to implement the separation of concerns by creating three tiers: Model, View, and Controller. More recently, the Model View Presenter pattern was released as an alteration of the MVC. The MVP's Presenter does more delegations to the view.

What is Model View Controller?
Model - The Model's responsiblity is to maintain state. A typical use for the Model is querying a database and and storing that data in a DTO (Data Transfer Object). The intent here is that the datasource can change and the conroller or view will still work as originally designed. The controller should not be aware of where the data came from or it's from LINQ, XML, or File.

View - The View's responsiblity is to present the information. This is typically done in the user interface. One example of a view would be Edit Customer.

Controller - The Controller is the glue that handles all of the interactions between the user interface (View) and the model. It does most of the heavy lifting by responding to a user interaction and manipulating the model. The view should only display information and does not care about the event handling. The controller also select which view to display based on the type of interaction.

What is REST?
REST - After reasearching ASP.NET MVC, I discovered that indeed it implements this pattern, but it also implements the Representational State Transfer (REST) architecture design as well. MVC uses a REST type archecture for it's routing mechanism. I needed to learn more about REST before going any further into my research. After learning more about REST, I trumpet this softly when I say this feature is one of the most compelling components of the ASP.NET MVC Framework.
Scott Gu's link below does an awesome job of detailing this routing system. Again, all of this is built into the framework so implement REST is quite easier than you think.

How is this different from Web Forms?
Web Forms use the Post Back model. MVC uses the framework's components along with routing architecture. Here is a diagram of how ASP.NET MVC works.

Simplified
















More Detailed












What is required to start developing?
Prerequisites - I have to admit, at first I thought it would be some libraries I would have to download and then just add them as references. IMHO, I feel like Microsoft has done a great job so far wrapping the required libraries and you will need to add a new project type 'MVC Web Project'. Here is what is required to start work:

Here is what I am using: Visual Studio 2008 with .NET 3.5 Framework, download ASP.NET MVC from Codeplex CTP release 4. Preview 5 was release August 28th.

References used:
Content based on research on the following sites:
MS Main MVC Page

Scott GU - REST

Phil Haack's: MVC History Lesson

Scott Hanselman's Walkthrough Video

Scott Gu

Dino Esposito on DotNetSlackers

Code Plex Download: MVC

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.



Sunday, August 24, 2008

Welcome! New Blog Site!

I will posting some new blogs soon!