MVC Convention-Over-Configuration Examples

1. A simple example of what Convention-Over-Configuration means is:

View files are often associated with an Action method(s) by means of a Naming Convention as opposed to being explicitly configured.

If the framework is requested to find the default view for an action called Index on a controller called HomeController, (if you don't specify a View name in the Action method) it will check the following four locations:

1. ~/Views/Home/Index.aspx
2. ~/Views/Home/Index.ascx
3. ~/Views/Shared/Index.aspx
4. ~/Views/Shared/Index.ascx

Unlike in traditional ASP.NET Web Forms, PHP, and many older web development platforms, URLs in ASP.NET MVC don't correspond to files on the server's hard disk—instead, they're mapped through a routing configuration onto a controller and action method. Each action method automatically has its own URL; you don't need to create a separate page or class for each URL.

How Does MVC Know Which Controller to Invoke?

As well as models, views, and controllers, ASP.NET MVC applications also use the routing system. This piece of infrastructure decides how URLs map onto particular controllers and actions. Under the default routing configuration, you could request any of the following URLs and it would be handled by the Index action on HomeController:

• /
• /Home
• /Home/Index

So, when a browser requests http://yoursite/ or http://yoursite/Home, it gets back the output from HomeController's Index method.

Should i use MVC or Webforms???

(copied verbatim from Pro ASP.NET MVC 2 Framework)

There are certainly cases where Web Forms is at least as good as, and probably better than, MVC. The obvious example is small, intranet-type applications that are largely about binding grids directly to database tables or stepping users through a wizard. Since you don't need to worry about the bandwidth issues that come with ViewState, don't need to be concerned with search engine optimization, and aren't bothered about unit testing or long-term maintenance, Web Forms' drag-and-drop development strengths outweigh its weaknesses.

On the other hand, if you're writing applications for the public Internet, or larger intranet applications (e.g., more than a few person-month's work), you'll be aiming for fast download speeds and cross-browser compatibility, built with higher-quality, well-architected code suitable for automated testing, in which case MVC will deliver significant advantages for you.

Notes from Pro ASP.Net MVC 2

• ASP.NET MVC—generated pages don't contain any ViewState data, so they can be hundreds of kilobytes smaller than typical pages from ASP.NET Web Forms
• ASP.NET MVC applications work well with UI automation testing tools. You can write scripts that simulate user interactions without having to guess what HTML element structures, CSS classes, or IDs the framework will generate or when it will change them.
• The Ruby community has created and popularized a new generation of BDD-oriented UI automation technologies (e.g., Cucumber and WebRat - this guy has a good example of working with both); these ideas are now slowly leaking into the .NET world.
• Controllers
  In model-view-controller (MVC) architecture, incoming requests are handled by controllers. In ASP.NET MVC, controllers are just simple C# classes (usually inheriting from System.Web.Mvc.Controller, the framework's built-in controller base class). ^[2] Each public method on a controller is known as an action method, which means you can invoke it from the Web via some URL.
• Model Binding
  An extremely useful feature of ASP.NET MVC whereby incoming data is automatically parsed and used to populate action method parameters by matching incoming key/value pairs with the names of properties on the desired .NET type
• Example:
  In your controller you have an Action Method "MyForm" which takes an instance of a bespoke class "MySpecialObj".
  What is special here is that "MyForm" responds directly to HttpPost requests...

• [HttpPost]
  public ViewResult MyForm(MySpecialObj mySpecialObj)
  {
        // This line tells ASP.NET MVC to find and render a view called       
        // DifferentView and to supply the mySpecialObj object to that view. 
        // Since this all happens in a controller called HomeController, 
        // ASP.NET MVC will expect to find the DifferentView view at 
        // ~/Views/Home/DifferentView.aspx
        return View("DifferentView", mySpecialObj);
  }

• Because the input controls defined in MyForm.aspx render with names corresponding to the names of properties on "MySpecialObj", the framework will supply to your action method a "MySpecialObj" instance already fully populated with whatever data the user entered into the form. 
•