MVC controller actions have structural likenesses with classic postback event handlers, which you know well from Web Forms. Before you label this sentence as pure blasphemy and turn your attention elsewhere, let me point out that the major structural differences you'll observe between ASP.NET MVC and ASP.NET Web Forms live outside the controller class. For example, you'll find many differences in the way in which the request is being processed—no page-based approach, radically different request life cycle, different way of forwarding posted data, different way of generating the next view.
What would you find instead in a controller class? A controller class is a plain container of methods. I dare say that a controller only exists because we need classes to hold actions to execute against HTTP requests. The controller class is stateless and it's instantiated for each and every request. Its lifetime is fairly short, because it lives only to execute the selected action method. Controller actions contain only the code that "handles" the "event" generated by the HTTP request being processed. Controller actions are, in this regard, the MVC counterpart of postback event handlers.
Both event handlers and controller actions need to collect input data, perform an action against the back-end of the system, and arrange obtained results into a nice piece of user interface to return to the browser. Both event handlers and controller actions can be written as a messy tangle of object calls. Choosing ASP.NET MVC instead of Web Forms neither automatically cleans up your code nor enhances your ability to write clean code. Writing clean code for controller actions, however, is simpler and in a way easier, thanks to some new goodies you'll find in the .NET Framework 4. Enter code contracts in the reign of ASP.NET MVC controllers.
Introduction to the Code Contracts API
Code Contracts (CC) is the name of the technology behind the new Contract class defined in the System.Diagnostics.Contracts namespace within mscorlib. The Contract class implements software contracts—an old concept in software design—according to which each function should expose the terms of the service it can provide using a formal and unified language. A software contract is the sum of three elements: preconditions, postconditions, and invariants.
Preconditions list the conditions under which the function will execute. Failing to fulfill any of the preconditions set for the method will prevent the method from running. Postconditions identify the results that the execution of the function ensures. Finally, invariants describe possible conditions that remain constant within the host class before and after the execution of any functions. CC in .NET 4 provides a comprehensive and unified API to express (even partially) software contracts.
In .NET 4 projects, you enable and configure CC through the properties of the project in Visual Studio 2010. Note that you can employ different settings for Debug and Release configurations. An evergreen question lies behind software contracts: Should you disable contracts in production? In .NET 4, the framework doesn’t hold any position and leaves it all to you.