ASP.net MVC Framwork

I remember from early days of my career, when I was working on Microsoft ASP 3.0 technology, keeping a separation of business and presentation logic was quite a challenge. Although, the critical business logic was often coded in COM components, which were called from ASP Page, but the ASP Page would still contain certain logic on which component to call and how the process flow in the application would happen. The resulting ASP files were often a horrid mesh of server side VB Script portions, client side javascript portions and HTML/DHTML to render a page.

To put some method to madness, and to achieve some separation of presentation and business logic, I was taught to create each ASP page with a “Main” method in it, called in the first command of the page. The Main method would provide a single point of entry to the page and used to look like

<% Call Main

Sub Main
Select _pageMode:
Case ADD_MODE:
'code to show the form in add mode

Case INSERT_MODE:
'code to add records

Case EDIT_MODE:
'code to add record Case EDIT_MODE

Case UPDATE_MODE:
'code to update records

.....
.....
End Select
End Sub
%>


....
....



So, what we had was essentially identification of action at the start of page and then business logic to do specific work for that action. The presentation of page would follow after all the server side script was executed. If there were any server side scriptlets in the HTML section, they were used just to present data.

As then, the separation of presentation and essential business logic is still identified as one of the salient features of application maintainability. And the Model View Controller pattern has fast become one of the most popular ways of achieving this.

The advent of ASP.Net saw the whole programming model of working with ASP pages to a more event driven structure. Certain events are fired are certain stage of a page’s execution. To do something similar in ASP.Net, an ordinary developer would identify the event where the code to handle the specific action needs to be written and then write down the code in the handler of that event. This model, along with the code behind ability of ASP.Net provides separation of presentation logic from business logic, but the code is still driven by view.

The purists would argue that in a real MVC pattern, the Controller controls the process flow and maps “actions” to appropriate “processes”. In other words, it would gather the action done by the user on the view, determine the state of application and then invoke the appropriate model.

The new Microsoft MVC framework, recently released by Microsoft is a lovely initiative to allow you to use the MVC framework without doing zillions of line of code. It also provides an alternative “off the shelf” approach to designing web applications for people who do not wish to use the server components, Post Backs, View state, etc.

In my next post, I will write about using MVC pattern in a simple ASP.Net web application and demonstrate how simple it is to do so with the ASP.Net MVC framework. Also, you will be surprised to note, how similar our controller would be the above mentioned template that was suggested for ASP.