All about patterns

A pattern describes a recurring problem that occurs in a given context and, based on a set of guiding forces, recommends a solution. The solution is usually a simple mechanism, a collaboration between two or more data objects, services, processes, threads, components, or nodes that work together to resolve the problem identified in the pattern.

Mainly, there are three levels of patterns :

• Design Patterns (e.g. GoF patterns)
• Architectural Patterns (e.g. Layers, MVC,MVP,MVVM, P2P )
• Implementation patterns (Idioms) (e.g. language specific patterns like Pimpl, RAII in C++)

In my previous article “Design Patterns” we have discussed about Design Patterns,I will briefly re-define then in this article and will discuss Architectural patterns specifically MVC,MVP and MVVM patterns and their implementation.At the end of this article i will take you to Microsoft Enterprise Library (applications blocks) version 5.0 which was recently released (April 2010) and will also discuss about few guidance from microsoft like Composite Application Guidance (CAG).

Design Patterns

The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. The authors Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are often referred to as the GoF, or Gang of Four.

They are categorized in three groups:

• Creational
• Structural and
• Behavioral

Lets discuss them in brief (for detail please visti my previous article “Design Patterns“)

• Creational Patterns
  • Abstract Factory : Creates an instance of several families of classes.
  • Builder :  Separates object construction from its representation.
  • Factory Method :  Creates an instance of several derived classes.
  • Prototype  :  A fully initialized instance to be copied or cloned.
  • Singleton  :  A class of which only a single instance can exist.
• Structural Patterns
  • Adapter : Match interfaces of different classes.
  • Bridge :  Separates an object’s interface from its implementation.
  • Composite :  A tree structure of simple and composite objects.
  • Decorator :  Add responsibilities to objects dynamically.
  • Facade :  A single class that represents an entire subsystem.
  • Flyweight :  A fine-grained instance used for efficient sharing.
  • Proxy :  An object representing another object.
• Behavioral Patterns
  • Chain of Resp. :  A way of passing a request between a chain of objects.
  • Command  :  Encapsulate a command request as an object.
  • Interpreter  : A way to include language elements in a program.
  • Iterator : Sequentially access the elements of a collection.
  • Mediator : Defines simplified communication between classes.
  • Memento : Capture and restore an object’s internal state.
  • Observer :  A way of notifying change to a number of classes.
  • State : Alter an object’s behavior when its state changes.
  • Strategy : Encapsulates an algorithm inside a class.
  • Template Method : Defer the exact steps of an algorithm to a subclass.
  • Visitor : Defines a new operation to a class without change.

Architectural Patterns

An Architectural Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Model View Controller (MVC), Model View Presenter (MVP) , Model View ViewModel (MVVM) falls under architectural pattern, to be more precise they are architectural presentation patterns. In this article we will discuss about MVC, MVP and MVVM and their implementation using .net c#. There are other patterns like Application Architecture Pattern (Client-Proxy Server,Customer Support,Reactor,Replicated Servers,Layered Architecture, Pipe and Filter Architecture … and so on ) which are not discussed here.

Model View Controller (MVC)

Model-View-Controller (MVC) is a architectural Patternoften used by applications that need the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean separation of objects into one of three categories — models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view(s).

Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design.

It is important to note that both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation. The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In Web applications, on the other hand, the separation between view (the browser) and controller (the server-side components handling the HTTP request) is very well defined.

Impelmenting MVC

Microsoft has published ASP.NET MVC Framework if you want to use MVC in your web porject.

The Model-View-Controller (MVC) pattern is an architectural design principle that separates the components of a Web application. This separation gives you more control over the individual parts of the application, which lets you more easily develop, modify, and test them.

ASP.NET MVC is part of the ASP.NET framework. Developing an ASP.NET MVC application is an alternative to developing ASP.NET Web Forms pages; it does not replace the Web Forms model.

Scott Gu says “If you are looking to build your web applications using a MVC approach, I think you’ll find this new ASP.NET MVC Framework option very clean and easy to use.  It will enable you to easily maintain separation of concerns in your applications, as well as facilitate clean testing and TDD.” Scott has written a series of blog posts on this new addition to the ASP.NET family. Read them:

Note: However, please do not blindly use MVC pattern for each and every website that you create. Like most of the design Patterns, the MVC has its own disadvantages like performance hits and writing extra code.Make sure you dont take the pain without a reason.

• ASP.NET MVC Framework
• ASP.NET MVC Framework (Part 1)
• ASP.NET MVC Framework (Part 2)
• ASP.NET MVC Framework (Part 3)
• ASP.NET MVC Framework (Part 4)

Again, MVC model is only an additional model/approach to develop ASP.NET applications and not a replacement for the existing rendering ASP.NET framework.

When to Create an MVC Application

You must consider carefully whether to implement a Web application by using either the ASP.NET MVC framework or the ASP.NET Web Forms model. The MVC framework does not replace the Web Forms model; you can use either framework for Web applications. (If you have existing Web Forms-based applications, these continue to work exactly as they always have.)

Before you decide to use the MVC framework or the Web Forms model for a specific Web site, weigh the advantages of each approach.

Advantages of an MVC-Based Web Application

The ASP.NET MVC framework offers the following advantages

• It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
• It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.
• It uses a Front Controller pattern that processes Web application requests through a single controller. This enables you to design an application that supports a rich routing infrastructure. For more information, see Front Controller.
• It provides better support for test-driven development (TDD).
• It works well for Web applications that are supported by large teams of developers and for Web designers who need a high degree of control over the application behavior.

Advantages of a Web Forms-Based Web Application

The Web Forms-based framework offers the following advantages:

• It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.
• It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller.
• It uses view state on server-based forms, which can make managing state information easier.
• It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
• In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.

I would like to discuss about ASP.Net MVC in separate dedicated article, for the time being you may explore the contents published by microsoft.

Note : Because ASP.NET MVC does not maintain state information by using view state, you must find other ways to manage state information, if you need it. In addition, server controls that rely on view state and postback will not work as designed in an ASP.NET MVC application. Therefore, you should not use controls such as the GridView, Repeater, and DataList controls.

Model View Presenter (MVP)

MVP is a derivative of MVC, mostly aimed at addressing the “Application Model” portion of MVC and focusing around the observer implementation in the MVC triad. Instead of a Controller, we now have a Presenter, but the basic idea remains the same – the model stores the data, the view is a representation of that data (not necessarily graphical), and the presenter coordinates the application.

Separate the responsibilities for the visual display and the event handling behavior into different classes named, respectively, the view and the presenter. The view class  manages the controls on the page and it forwards user events to a presenter class. The presenter contains the logic to respond to the events, update the model (business logic and data of the application) and, in turn, manipulate the state of the view.

To facilitate testing the presenter, make the presenter have a reference to the view interface instead of to the concrete implementation of the view. By doing this, you can easily replace the real view with a mock implementation to run tests.

When the model is updated, the view also has to be updated to reflect the changes. View updates can be handled in several ways. The Model-View-Presenter variants, Passive View and Supervising Controller, specify different approaches to implementing view updates.

In Passive View, the presenter updates the view to reflect changes in the model. The interaction with the model is handled exclusively by the presenter; the view is not aware of changes in the model.

In Supervising Controller, the view interacts directly with the model to perform simple data-binding that can be defined declaratively, without presenter intervention. The presenter updates the model; it manipulates the state of the view only in cases where complex UI logic that cannot be specified declaratively is required.

The decision to use Passive View or Supervising Controller primarily depends on how testable you want your application to be. If testability is a primary concern in your application, Passive View might be more suitable because you can test all the UI logic by testing the presenter. On the other hand, if you prefer code simplicity over full testability, Supervising Controller might be a better option because, for simple UI changes, you do not have to include code in the presenter that updates the view. When choosing between Passive View and Supervising Controller, consider the following:

• Both variants allow you to increase the testability of your presentation logic.
• Passive View usually provides a larger testing surface than Supervising Controller because all the view update logic is placed in the presenter.
• Supervising Controller typically requires less code than Passive View because the presenter does not perform simple view updates.

You can implement the interaction with the model in several ways. For example, you can implement the Observer pattern. This means that the presenter receives events from the model and updates the view as required. You may explore the Observer pattern in this artcile.

MVC vs MVP

• With MVC, it’s always the controller’s responsibility to handle mouse and keyboard events.
• With MVP, GUI components themselves initially handle the user’s input, but delegate to the interpretation of that input to the presenter.
• In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller. Thus MVP pattern is widely used in WinForms, .NET SmartClient Factory, etc.
• In most web architectures, the MVC pattern is used (e.g. Struts, ASP.NET MVC etc)
• MVP is a derivative of MVC, mostly aimed at addressing the “Application Model” portion of MVC and focusing around the observer implementation in the MVC triad. Instead of a Controller, we now have a Presenter, but the basic idea remains the same – the model stores the data, the view is a representation of that data (not necessarily graphical), and the presenter coordinates the application.
• In MVP the Presenter gets some extra power. It’s purpose is to interpret events and perform any sort of logic necessary to map them to the proper commands to manipulate the model in the intended fashion. Most of the code dealing with how the user interface works is coded into the Presenter, making it much like the “Application Model” in the MVC approach.

Presentation Model (PM)

Model View ViewModel (MVVM)

Continues with article “All About MVVM“