Asp.net MVC Vs Web Farms Application

Asp.Net MVC is not a replacement for the Web Forms model of Asp.net application, each has its own advantages and disadvantages, it is up to the user to decide on which model to user based on the requirements and other factors.

In this post we shall compare the features of Asp.Net MVC Applications and Web Farms Application

Asp.Net MVC Applications	Web Farms Application
UI Design is places in the View (.aspx) files. Implementation logic is placed in the Controller (.cs) classes. Data logic is placed in the Model (.cs) classes.	UI design is placed in the .aspx files and the implementation logic is placed in the code-behind .cs / .vb files
Provides better support for better support for test-driven development, since the UI, Implementation and Data logic are placed in different files.	Test-driven development is complex compared to the MVC architecture since UI and Implementation are not completely isolated.
Binds seamlessly with client side scripting frameworks like JavaScript, jQuery etc	Works with client side scripting frameworks like JavaScript, jQuery etc, but not completely flexible to adopt with these frameworks.
Supported from .Net Framework 3.5 and above	Supported from .Net Framework 1.1 and above
Application development is complex and takes more time compared to the Web Forms model.	Enables rapid application development
Fully supports Automated testing.	Automated testing of an ASP.NET Web Forms application is difficult.
Controls needs to be manually scripted in the View .aspx pages.	Allows Drag and Drop of HTML / Service side controls in the .aspx page.
HTTP Get/Post requests are handled by the Controller UI Design in handled by the View Business Logic and Data access are handled by the Model	UI Design and HTTP Get/Post requests are handled by the .aspx page Business and Data access are handled by the code-behind .cs/.vb files
Represents MVC architecture	Represents an n-tier architecture
View State is not maintained, and there is no concept of Post back, developers will have to handle form data using the Model.	Uses View State to persist information between post backs
Ideal for large applications which involves large teams, and each team focuses on a separate aspect (Design / Implementation)	Ideal for small applications which involves small teams.
Uses a Front Controller pattern where all the requests are handled by the controller and routed to the appropriate view based on the request.	Uses the Page Controller pattern where all the designed is configured in a single page.
Does not support Event model, control events have to be handled by passing appropriate parameters during form post.	Supports an event mode, where the events of each control in the page can be handled individually.