ASP.NET MVC Design

ASP.NET MVC Design pattern derives from MVC design pattern i.e. Model View Controller design pattern. It seperates the responsibilities.C in MVC is for Controller. Controller is component which acts as target to external stimulus. Controller then responds to stimulus by calling Model to fetch data and then View to display data in UI .

ASP.NET MVC Design pattern seperates the behaviour i.e. Data , UI and Event.

What is Abstract Factory Pattern ?

Abstract Factory Pattern

Abstract Factory Pattern is type of Creational pattern . This is used to create objects of related class without specify concrete class.

Abstract Factory has :

1) Abstarct Factory – declares an interface for operations that create abstract product objects.

2) Concrete Factory – implements the operations to create concrete product objects.

3) Abstract Product – declares an interface for a type of product object.

4) Concrete Product – defines a product object to be created by the corresponding concrete factory. It implements the Abstract Product interface.

5) Client – uses only interfaces declared by Abstract Factory and Abstract Product classes.

What is singleton design pattern ?

Singleton design pattern

Singleton design pattern is type of Creational Design pattern . It creates a single instance object which caters to all the clients.

Singleton Design pattern has :

It has private constructor so that instance of class cannot be created anywhere but inside its own methods.
It has static read only member so that instance is created only once .
It has an instance property to return singleton object instance

Code snippet for simple singleton :

public sealed class Singleton

{

// private constructor

private Singleton()

{

}

// static readonly member

static readonly Singleton instance = new Sinleton();

// static instance property

Singleton Instance

{

get { return instance ; }

}

Singleton Design Pattern in C#

Singleton Design pattern ensures a class has only one instance and provide a global point of access to it.

Simple Singleton Design Pattern – Not thread safe

Code Snippet showing a simple Singleton Design pattern :
///

/// The ‘Singleton’ Design Pattern
///

public class Singleton
{
// Define a static class variable
private static Singleton _instance;
// Have a private Constructor
private Singleton()
{
}
public static Singleton Instance()
{
// Uses lazy initialization.
// Note: this is not thread safe.
if (_instance == null)
{
_instance = new Singleton();
}
return _instance;
}
}
Above implementation has below advantages:

• Singleton provides lazy instantiation i.e the instantiation is not performed until an object asks for an instance. Lazy instantiation avoids instantiating unnecessary singletons when the application starts.

Above implementation has below disadvantages:

•Above implementation of Singleton class is not safe for multithreaded environments. If separate threads of execution enter the Instance property method at the same time, more that one instance of the Singleton object may be created.
Below are two approaches solve this problem.

One approach is to use Double-Check Locking .
Second approach is to use static initialization approach.

Singleton Design Pattern – Static Initialization

public sealed class Singleton

{
    private static readonly Singleton instance = new Singleton();
    private Singleton(){}
    public static Singleton Instance
   {
       get { return instance; }
    }
}
The class is marked sealed to prevent derivation, which could add instances. The variable is marked readonly, which means that it can be assigned only during static initialization (which is shown here) or in a class constructor.

Singleton Design Pattern – Thread safe

Code Snippet showing a Thread Safe Singleton Design pattern :
///

/// The ‘Singleton’ Design Pattern
///

public class Singleton
{
// Define a static class variable
private static Singleton _instance;
private static object syncRoot = new Object();
// Have a private Constructor
private Singleton()
{
}
public static Singleton Instance()
{
// Uses lazy initialization.
// Note: this is thread safe.
lock (syncRoot)
{
if (_instance == null)
_instance = new Singleton();
}
return _instance;
}
}

Design Pattern Snapshot

Factory Method Pattern

Purpose

The Factory Method pattern is a type of creational pattern. Subclasses decide exactly which class to instantiate in Factory Method. The Factory Method instantiates the appropriate subclass based on information supplied by the client or extracted from the current state.

Singleton Pattern

Purpose

Singleton pattern ensures that there is only one instance of a class . All the client uses this single instance of a class.

Decorator Pattern

Purpose

Decorator pattern is used to attach new state and behavior to an object dynamically. The object does not know it is being “decorated,” which makes this a useful pattern for evolving systems.

Composite Pattern

Purpose

The Composite pattern arranges structured hierarchies so that single components and groups of components can be treated in the same way. Typical operations on the components include add, remove, display, find, and group.

Proxy Pattern

Purpose

The Proxy pattern supports objects that control the creation of and access to other objects. The proxy is often object that stands in for a more complex object that is activated once certain circumstances are clear.

Flyweight Pattern

Purpose

The Flyweight pattern promotes an efficient way to share common information present in small objects that occur in a system in large numbers. It thus helps reduce storage requirements when many values are duplicated. The Flyweight pattern distinguishes between the intrinsic and extrinsic state of an object. The greatest savings in the Flyweight pattern occur when objects use both kinds of state but:
• The intrinsic state can be shared on a wide scale, minimizing storage requirements.
• The extrinsic state can be computed on the fly, trading computation for storage.

Bridge Pattern

Purpose

The Bridge pattern decouples an abstraction from its implementation, enabling them to vary independently. The Bridge pattern is useful when a new version of software is brought out that will replace an existing version, but the older version must still run for its existing client base. The client code will not have to change, as it is conforming to a given abstraction, but the client will need to indicate which version it wants to use.

Adapter Pattern

Purpose

The Adapter pattern enables a system to use classes whose interfaces don’t quite match its requirements. It is especially useful for off-the-shelf code, for toolkits, and for libraries.

Prototype Pattern

Purpose

The Prototype pattern creates new objects by cloning one of a few stored prototypes.It speeds up the instantiation of very large, dynamically loaded classes (when copying objects is faster), and it keeps a record of identifiable parts of a large data structure that can be copied without knowing the subclass from which they were created.

Facade Pattern

Purpose

The role of the Façade pattern is to provide different high-level views of subsystems whose details are hidden from users. In general, the operations that might be desirable from a user’s perspective could be made up of different selections of parts of the subsystems.

Abstract Factory Pattern

Purpose

This pattern creates products that exist in families. The abstract factory can be refined to concrete factories, each of which can create different products of different types and in different combinations. The pattern isolates the product definitions and their class names from the client so that the only way to get one of them is through a factory.

Builder Pattern

Purpose

The Builder pattern is used to separate the specifications of a complex object from its actual construction. The same construction process can create different representations.