Jack @ ASP.NET

Key characteristics of VIEW
? The view is a visual element, such as a window, page, user control, or data template. The view defines the controls contained in the view and their visual layout and styling.
? The view references the view model through its DataContext property. The controls in the view are data bound to the properties and commands exposed by the view model.
? The view may customize the data binding behavior between the view and the view model. For example, the view may use value converters to format the data to be displayed in the UI, or it may use validation rules to provide additional input data validation to the user.
? The view defines and handles UI visual behavior, such as animations or transitions that may be triggered from a state change in the view model or via the user’s interaction with the UI.
? The view’s code-behind may define UI logic to implement visual behavior that is difficult to express in XAML or that requires direct references to the specific UI controls defined in the view.

Key characteristics of’ ‘VIEWMODEL’
? The view model is a non-visual class and does not derive from any WPF or Silverlight base class. It encapsulates the presentation logic required to support a use case or user task in the application. The view model is testable independently of the view and the model.
? The view model typically does not directly reference the view. It implements properties and commands to which the view can data bind. It notifies the view of any state changes via change notification events via the INotifyPropertyChanged and INotifyCollectionChanged interfaces.
? The view model coordinates the view’s interaction with the model. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model. It may also implement data validation via the IDataErrorInfo or INotifyDataErrorInfo interfaces.
? The view model may define logical states that the view can represent visually to the user.

Key characteristics of ‘MODEL’
? Model classes are non-visual classes that encapsulate the application’s data and business logic. They are responsible for managing the application’s data and for ensuring its consistency and validity by encapsulating the required business rules and data validation logic.
? The model classes do not directly reference the view or view model classes and have no dependency on how they are implemented.
? The model classes typically provide property and collection change notification events through the INotifyPropertyChanged and INotifyCollectionChanged interfaces. This allows them to be easily data bound in the view. Model classes that represent collections of objects typically derive from the ObservableCollection<T> class.
? The model classes typically provide data validation and error reporting through either the IDataErrorInfo or INotifyDataErrorInfo interfaces.
? The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.

The ASP.NET  MVC  is becoming more and more popular each day.  As the application grows in size so does the maintenance nightmare.  Following are some of the better practices, that if followed, may help maintain our application and also provides a means of scalability as the demand increases.  Feel free to add/update practices as required.

1. Isolate Controllers
   Isolate the controllers from dependences on HttpContext, data access classes, configuration, logging etc.  Isolation could be achieved by creating wrapper classes and using an IOC container for passing in these dependencies
2. IoC Container
   Use an IoC container to manage all external dependencies  The following are some of the wellknown containers/framework.
   1. Ninject
   2. Autofac
   3. StructureMap
   4. Unity Block
      
      
3. No "magic strings"m
   Never use magic string in your code.   More to come on this.
4. Create a ViewModel for each view
   Create a specialized ViewModel for each view.  The role of ViewModel should only be databinding.  It should not contain any presentation logic.
5. HtmlHelper
   For generating view html use HtmlHelper.  If  the current HtmlHelper is not sufficient extend it using extension methods.  This will keep the design in check.
6. Action Methods
   Decorate your action methods with appropriate verbs like Get or Post as applicable.
7. Caching
   Decorate your most used action methods with OutputCache attribute.
   
   
8. Controller and Domain logic
   Try to keep away domain logic from controller.  Controller should only be responsible for
   1. Input validation and sanitization.
   2. Get view related data from the model.
   3. Return the appropriate view or redirect to another appropriate action method.
      
9. Use PRG pattern for data modification
   PRG stands for Post-Redirect-Get to avoid the classic browser warning when refreshing a page after post.  Whenever you make a POST request, once the request complets do a redirect so that a GET request is fired.  In this way when the user refresh the page, the last GET request will be executed rather than the POST thereby avoiding unnecessary usability issue.
   
   
10. Routing
    Design your routes carefully.  The classic route debugger comes to rescue http://haacked.com/archive/2008/03/13/url-routing-debugger.aspx