This topic contains a brief description about ASP.NET MVC. If you are looking for ASP.NET MVC Hosting, you can always consider ASPHostCentral and you can start from our lowest Standard Plan @$4.99/month to host your .NET MVC site.


At DevConnections Fall and TechEd Europe, Microsoft recently unveiled the ASP.NET MVC Framework. MVC stands for Model-View-Controller and is one of the most popular design patterns for decoupling data access and business logic from data presentation and user interaction. At the time of this writing, the framework is not available yet, not even as a CTP. However, the first CTP is expected to ship in just a few weeks.

In any case, the ASP.NET MVC Framework is definitely worth a look since it addresses aspects of programming that are extremely important for developers and their productivity such as code reusability, testing, and separation of presentation and business logic concerns. At the same time, an early look at the MVC Framework may generate good feedback to Microsoft and help them to deliver a better and richer product in full accordance with the community expectations and needs.

Motivating the Hype on MVC

Most applications, and especially Web applications, have their presentation layer mixed up with some business logic and data access code. As an example, think of a classic ASP.NET page. You define the user interface by composing and configuring server controls until you obtain the desired markup. Next, you use a code-behind class to add some handlers for the various events fired by controls and provide any required glue code. In such pages, more often than not, data access code is interspersed with presentation logic. In ASP.NET 2.0, the introduction of data source controls certainly didn't make this mixture more unlikely. Some data source controls, such as the SqlDataSource control, are a sinful temptation for developers as they see in it the way to go down to SQL queries and stored procedures - the raw data - very quickly. Without beating the bush around, such ASP.NET pages whose code-behind classes contain a mixture of presentation, business and data access code, are quite difficult to maintain. And they are definitely challenging to test appropriately.

User interface facilities (i.e., wizards and tools in Visual Studio) tend to encourage developers to put in the presentation layer more than it should. The presentation layer acts as a catch-all for logic that reasonably belongs to other layers. At the end of the day, you can still have the application working and perform well. Behind the scene, though, you get a too high level of coupling and subsequently high costs of maintenance. What if, in fact, at some point you need to add a new feature or re-implement an existing one? Not having a well designed structure of classes and lacking a clean separation of presentation, business and data layers, most that you can do is cutting and pasting code and run pages over and over again to test results against expectations.

There's not much of reusability too, but quite the reverse we'd say. Code duplication is not unlikely and the need of changing the view for the same data may often result in serious trouble.

Sure, there are architectural design patterns to give you guidance on the best way to design Web applications with cleanly separated layers. However, these patterns require a lot of coding, sometimes repetitive code, which doesn't always sit well with the rush of delivering applications that just work. While the startup costs of implementing recognized patterns manually will certainly pay you off in the context of complex enterprise applications, it seems to be an unnecessary complication in simpler, but still realistic, scenarios.

The classic code-behind model of ASP.NET provides the tools for building great and well-designed applications, but it leaves most of it up to the individual developer or team. As a result, too many applications out there work well, but are not well designed. Over the years, this fact raised the need of a radically different approach to Web programming. The MVC pattern was soon identified as an excellent approach to Web development. MVC ensures a clean separation between the data model and the user interface in such a way that changes to the user interface don't affect data handling. At the same time, the data model and related access code can be refactored without the need of changing the user interface accordingly.

Where Did We See This Already?

Tools like Castle MonoRail have been created to simplify Web development by leveraging the MVC pattern. Where's the difference between MonoRail and ASP.NET? It mostly lies in an extremely simplified form of the code that backs a page up. It's like breaking the code you have in, and reference from, the code-behind class into distinct elements. The controller handles application flow; the model represents the data; the view takes care of presentation. The underlying engine automates some tasks for you (i.e., binding data to form elements) and exposes just plugs for you to connect and customize the engine. As a result, you write less code and have highly specialized components that are easier to test and maintain.  

At the same time, MonoRail is not necessarily better than Web Forms and may not be the right choice for just everybody. Because it propounds a different paradigm, it may not be the ideal environment for those who have strong ASP.NET skills and find it difficult (or just not affordable) to convert large applications.

By the way, regardless of the Mono prefix in the name there's no necessary connection between this project and the Mono project aimed at providing the code to run .NET applications on multiple platforms.

Comparing the MVC Framework to Classic ASP. Net

The ASP.NET MVC Framework is essentially the Microsoft's attempt to create an ASP.NET programming environment centered around the MVC pattern. For the time being (nobody can reasonably foresee future evolutions), the MVC Framework should be considered an alternative to Web Forms. To some extent, the MVC Framework and Web Forms have in common more or less what cars and motorcycles share. Both can take you somewhere else, but with different speed, comfort, sense of freedom, size of the trunk.

The MVC Framework doesn't support classic postbacks and viewstate and doesn't consider any URL as the endpoint to a physical server file to parse and compile to a class. In ASP.NET, you have a 1:1 correspondence between a URL and a resource. The only exception to this rule is when you use completely custom HTTP handlers bound to a particular path.

In the MVC Framework, a URL is seen as the mean to address a logical server resource, but not necessarily an ASPX file to parse. So the URLs employed by the pages of an MVC Framework application have a custom format that the application itself mandates. In the end, the MVC Framework employs a centralized HTTP handler that recognizes an application-specific syntax for links. In addition, each addressable resource exposes a well-known set of operations and a uniform interface for executing operations.

Have you ever heard about Representational State Transfer, or REST for short?

Well, REST is an architectural pattern that defines how network resources should be defined and addressed in order to gain shorter response times, clear separation of concerns between the front-end and back-end of a networked system. REST is based on three following principles:

1. An application expresses its state and implements its functionality by acting on logical resources
2. Each resource is addressed using a specific URL syntax
3. All addressable resources feature a contracted set of operations

As you can see, the MVC Framework fulfills it entirely.

So here's an alternate way of looking at the MVC Framework. It is an ASP.NET framework that performs data exchange by using a REST model versus the postback model of classic ASP.NET. Each page is split into two distinct components -controller and view - that operate over the same model of data. This is opposed to the classic code-behind model where no barrier is set that forces you to think in terms of separation of concerns and controllers and views. However, by keeping the code-behind class as thin as possible, and designing the business layer appropriately, a good developer could achieve separation of concerns even without adopting MVC and its overhead. MVC, however, is a model superior to a properly-done code-behind for its inherent support for test-driven development.

While MVC is definitely a key part of the framework, we wouldn't consider it is the most compelling part. REST is a possible alternative to the postback model, whereas MVC is an alternative to code-behind.

Explaining the MVC Framework to ASP. Net Developers

We wonder what's the quickest and most effective way to explain the MVC Framework to seasoned ASP.NET developers. It's like having a central HTTP handler that captures all requests to resources identified with a new extension. This HTTP handler analyzes the syntax of the URL and maps it to a special server component known as the controller. The controller supports a number of predefined actions. The requested action is somehow codified in the URL according to an application-specific syntax. The central HTTP handler invokes the action on the controller and the controller will process the request up to generating the response in whatever response format you need. The response is generated through a view component.

What here we called the "central HTTP handler" plays the same role that was of the System.Web.UI.Page class in classic ASP.NET. The Page is the handler responsible for any .aspx request
and generates the markup using the code-behind class and serves it back using postbacks. In the MVC Framework, this pattern - hard-coded in the ASP.NET runtime and not subject to change until the whole ASP.NET platform is rewritten - is simply implemented using an alternative HTTP handler and an alternative model based on REST and MVC.

Top Reasons to trust your ASP.NET MVC website to

What we think makes so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in ASP.NET MVC Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!