Design Patterns Overview

Software professionals may be familiar with the term "Design Patterns," but many have no idea of where they come from and what they truly are. Consequently, some do not see the value and benefits design patterns bring to the software development process, especially in the areas of maintenance and code reuse. This article will bridge this gap by defining design patterns from a historical perspective.

What is design Patterns:
A design pattern can solve many problems by providing a framework for building an application. Design patterns, which make the design process cleaner and more efficient, are especially well-suited for use in C# development because it is an object-oriented language. So design patterns are recurring solutions to software design problems you find again and again in real-world application development.

Benefits of Design Patterns
Design patterns have two major benefits. First, they provide you with a way to solve issues related to software development using a proven solution. The solution facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain. Second, design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.

Core Categories Of DP
-Creational
-Structural
-Behavioral

Just for info ,other than the main core category we have many design patterns like Concurrency pattern,Process pattern

Creational Design Patterns: The patterns in this category deal with object creation mechanisms by trying to create objects in a manner suitable to the situation.
For example, you want to create an object creation delayed at runtime instead of compile time, or you want a system to have only one object can exist of a class.
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 in which only a single instance can exist

Structural Design patterns: The pattern in this category provide solutions to the problems dealing with the composition of objects
For example, Assume you want to bring different incompatible interface together or want to bring unified interface together
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.
√ Façade:-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: The pattern in this category provide solutions to the problems dealing with the way object interact with each other. These patterns help to increase the flexibility in establishing the communication among various system objects.
Example ,you want to change an object behavior when its internal state changes.
Behavioral Patterns
√ Mediator:-Defines simplified communication between classes.
√ Memento:-Capture and restore an object's internal state.
√ Interpreter:-A way to include language elements in a program.
√ Iterator:-Sequentially access the elements of a collection.
√ Chain of Resp:-A way of passing a request between a chain of objects.
√ Command:-Encapsulate a command request as an object.
√ State:-Alter an object's behavior when its state changes.
√ Strategy:-Encapsulates an algorithm inside a class.
√ Observer:-A way of notifying change to a number of classes.
√ Template Method:-Defer the exact steps of an algorithm to a subclass.
√ Visitor:-Defines a new operation to a class without change.

Before starting the UML Diagram of a design pattern,I would like to explain a simple class diagram to understand the different UML notation and relationship.

First observe the diagram


UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.
Our class diagram has three kinds of relationships.
a)association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.
b)aggregation -- an aggregation in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails.
c)generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

0..1 =zero or one instance. The notation n . . m indicates n to m instances.
0..* or * =no limit on the number of instances (including none).
1 =exactly one instance
1..*= at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional.



Lets firts describe a Factory Pattern.

Factory Pattern
Its Creates an instance of several derived classes.
“Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.” -- "Design Patterns” Gamma et al., Addison-Wesley, ISBN:0-201-63361-2”



The following is an UML representation of the Factory Method Pattern. In this case we are not directly creating an instance of the class Derived1 and Derived2. Instead we are using the getObject() method of the Factory class to return an appropriate instance depending on the value passed to the getObject() method. This method is commonly knows as the Factory method and Factory method can be either static or non-static in nature.





In Factory method pattern, A Factory class contains a factory method is used for creating the object. This factory method can be either static or non-static.
Client class needn’t know about instance creation.

Abstract Factory:It "Provide an interface for creating families of related or dependent objects without specifying their concrete classes" -- "Design Patterns" Gamma et al., Addison-Wesley, ISBN:0-201-63361-2"


Builder Pattern:Builder is an object creational design pattern that codifies the construction process outside of the actual steps that carries out the construction - thus allowing the construction process itself to be reused.





Singleton pattern:A class in which only a single instance can exist.
The purpose of a singleton pattern is to ensure a unique instance of the class and to provide global access to this.
It maintain the unique instance throughout the life of the program(s) in which this class is created.
The logic of the CreateInstance method is pretty straightforward. Check, if any instance has already been created, if yes, return the instance, else create and store the instance and return it. It is obvious here again, storing the instance has to be done in a private static variable, static because, you are doing this in a static method, private because, you need to do the maintenance of the singleton instance creation.




Adapter Class:During object-oriented developments, some times we have to use an unrelated class along with our existing class hierarchy. The simplest solution is to make a wrapper or adaptor around the foreign class, which is acceptable by the existing class hierarchy. This is what known as the ADAPTOR PATTERN or WRAPPER PATTERN.
Lets take a non-software Example
Socket wrenches provide an example of the Adapter. A socket attaches to a ratchet, provided that the size of the drive is the same. Typical drive sizes in the United States are 1/2" and 1/4". Obviously, a 1/2" drive ratchet will not fit into a 1/4" drive socket unless an adapter is used. A 1/2" to 1/4" adapter has a 1/2" female connection to fit on the 1/2" drive ratchet, and a 1/4" male connection to fit in the 1/4" drive socket. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54]

Let us see the following class hierarchy.

How we can fit a foreign class or interface say ADAPTEE to this class hierarchy. It is possible by introducing an ADAPTOR class as shown below.

In the above case the ADAPTOR class inherits from both BASE CLASS & ADAPTEE class. This type of mechanism based on the multiple inheritances is known as class adaptors. Remember that this may be introducing the violation of Open Closed Principle (OCP) or Lisknov's Substitution Principle (LSP). But if we are using class adaptors, better to use a private inheritance with respect to the ADAPTEE class.

The Open Closed Principle states that classes should be open for extension but closed for modification. Or to say it another way, it should be possible to add new features and capabilities to your codebase simply by creating new classes, rather than having to mess with the internals of existing classes.

Likov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

Instead of inheriting from the ADAPTEE class, the ADAPTOR class can contain an instance of ADAPTEE class and use that instance. This mechanism employs the object adaptors. The UML representation of Object adaptor is shown below.



In class adaptor, it is possible to override some of the behaviors of the ADAPTEE class in ADAPTOR class. But class adaptor will not work when we want to adapt ADAPTEE class and all its derived classes.

But an object adaptor can work with the ADAPTEE class and all its subclasses.

Implementation of Builder Pattern

Builder pattern:Seperates object constructions from its representation.

using System;
using System.Collections.Generic;
using System.Text;

namespace BuilderPattern
{
interface IBuilder
{
void DoIt();
}
class BuilderA:IBuilder
{
public void DoIt()
{
Console.WriteLine("BuilderA is called");
}
}
class BuilderB : IBuilder
{
public void DoIt()
{
Console.WriteLine("BuilderB is called");
}
}
class Director
{
public void Construct(IBuilder builder)
{
builder.DoIt();
}
}
class Program
{
static void Main(string[] args)
{
Director d = new Director();
IBuilder build = new BuilderA();
d.Construct(build);
Console.ReadLine();
}
}
}

Output:

Implementation of Singleton Pattern

Singleton pattern:A class in which only a single instance can exist.

using System;
using System.Collections.Generic;
using System.Text;

namespace SingletonPattern
{
public class Singleton
{
private static Singleton singletonInstance;
// Constructor is 'protected',so intance can't be created outside,
//only the createInstance() create the instance of Singleton class
protected Singleton()
{

}
public static Singleton createInstance()
{
if (singletonInstance == null)
{
singletonInstance = new Singleton();
}
return singletonInstance;
}
}

class Program
{
static void Main(string[] args)
{
// Constructor is protected -- cannot use new
Singleton s1 = Singleton.createInstance();
Singleton s2 = Singleton.createInstance();

// Test for same instance
if (s1 == s2)
{
Console.WriteLine("Objects are the same instance");
}
Console.ReadLine();
}
}
}

Output:

Implementation of factory Pattern

What is a Factory Pattern :Factory Pattern creates an instance of several derived classes.

using System;
using System.Collections.Generic;
using System.Text;

namespace FactoryPattern
{
interface IBase
{
void DoIt();
}
class Derived1:IBase
{
public void DoIt()
{
Console.WriteLine("Derived1 Method is called");
}
}
class Derived2:IBase
{
public void DoIt()
{
Console.WriteLine("Derived2 Method is called");
}
}
class Factory
{
public IBase getObject(int type)
{
IBase objIBase = null;
switch (type)
{
case 1:
objIBase = new Derived1();
break;
case 2:
objIBase = new Derived2();
break;
}
return objIBase;
}
}
class Program
{
static void Main(string[] args)
{
Factory objFactory = new Factory();
IBase objIbase = objFactory.getObject(1);
objIbase.DoIt();
Console.ReadLine();
}
}
}

Output:


Diagram/Description

Static Constructor

What is Static Constructor:
C# supports two types of Constructor
1.Class Constructor or Static Constructor-used to initialize static data members as soon as the class is referenced first time
2.Instance Constructor or non-Static Constructor-used to create an instance of that class with new keyword.
Static Data Member can be initialized at the time of their declaration(clsWithoutStaticConstructor in the following example) but there are times when value of one static member (clsWithStaticConstructor in the following example)may depend upon the value of another static member.

using System;
using System.Collections.Generic;
using System.Text;

namespace StaticConstructor
{
class clsWithoutStaticConstructor
{
private static int numStatData = 8;
public static int StatData
{
get { return numStatData; }
}
public static void print()
{
Console.WriteLine("Static Data :" + StatData);
}
}
class clsWithStaticConstructor
{

private static int numStatData2;
static clsWithStaticConstructor()
{

if (clsWithoutStaticConstructor.StatData < 10)
{
numStatData2 = 10;
}
else
{
numStatData2 = 100;
}
Console.WriteLine("Static Constructor is called...");
}
public static void print2()
{
Console.WriteLine("Static Data :" + numStatData2);
Console.ReadLine();
}
}
class Program
{

static void Main(string[] args)
{
clsWithoutStaticConstructor.print();
clsWithStaticConstructor.print2();
}
}
}

Output :


In the above example "numStatData2" in "clsWithStaticConstructor" is initialized based on the value of clsWithoutStaticConstructor.StatData .since StatData in the clsWithoutStaticConstructor is initilized to 8 so the value of numStatData2 is set to 10.

Static Constructor executes:
-before any instance of the class is created.
-before any of the static members for the class are referenced.
-after the static field initializers(if any) for the class.
-atmost one time.

and a static constructor does not take access modifiers or have parameter

Tutorial 8-UML Diagram:Component and deployment diagrams

8.Component and deployment diagrams
A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams show the physical configurations of software and hardware.

The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.



The physical hardware is made up of nodes. Each component belongs on a node. Components are shown as rectangles with two tabs at the upper left.

Tutorial 7-UML Diagram:Activity diagrams

7.Activity diagrams
An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. A single transition comes out of each activity, connecting it to the next activity.

A transition may branch into two or more mutually exclusive transitions. Guard expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent merge marking the end of the branch appear in the diagram as hollow diamonds.

A transition may fork into two or more parallel activities. The fork and the subsequent join of the threads coming out of the fork appear in the diagram as solid bars.

Tutorial 6-UML Diagram:Statechart diagrams

6.Statechart diagrams

Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state.

Our example diagram models the login part of an online banking system. Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation.

Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. From each state comes a complete set of transitions that determine the subsequent state.

States are rounded rectangles. Transitions are arrows from one state to another. Events or conditions that trigger transitions are written beside the arrows. Our diagram has two self-transition, one on Getting SSN and another on Getting PIN.

The initial state (black circle) is a dummy to start the action. Final states are also dummy states that terminate the action.

The action that occurs as a result of an event or condition is expressed in the form /action. While in its Validating state, the object does not wait for an outside event to trigger a transition. Instead, it performs an activity. The result of that activity determines its subsequent state.

Tutorial 5-UML Diagram:Collaboration diagrams

5.Collaboration diagrams
Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.

The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons ( : ).

Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

Tutorial 4-UML Diagram:Sequence diagrams

4.Sequence diagrams
Class and object diagrams are static model views. Interaction diagrams are dynamic. They describe how objects collaborate.

A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.

Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window.


The Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message.

In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to make sure there is available room for each day of the stay in the hotel). The expression in square brackets, [ ], is a condition.

The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put into any kind of UML diagram.

Tutorial 3-UML Diagram:object diagrams

3.Packages and object diagrams
To simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. The diagram below is a business model in which the classes are grouped into packages.


Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle. The dotted arrows are dependencies. One package depends on another if changes in the other could possibly force changes in the first.

Object diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other Departments.



The object diagram below instantiates the class diagram, replacing it by a concrete example.



Each rectangle in the object diagram corresponds to a single instance. Instance names are underlined in UML diagrams. Class or instance names may be omitted from object diagrams as long as the diagram meaning is still clear.

Tutorial 2-UML Diagram:Class diagrams

2.Class Diagram
A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.
The class diagram below models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.



UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.
Our class diagram has three kinds of relationships.
a)association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.
b)aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails.
c)generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

0..1 =zero or one instance. The notation n . . m indicates n to m instances.
0..* or * =no limit on the number of instances (including none).
1 =exactly one instance
1..*= at least one instance


Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional .


Difference between Composition and Aggregation
Composition:

As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier, we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond

If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?

public class Engine
{
. . .
}

public class Car

{

Engine e = new Engine();

.......

}

As you can see in the example code above, Car manages the lifetime of Engine.

Aggregation:
The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond


So how do we express the concept of aggregation in C#? Well, it's a little different to composition. Consider the following code:

public class Address
{
. . .
}

public class Person

{

private Address address;

public Person(Address address)

{

this.address = address;

}

. . .

}

Person would then be used as follows:

Address address = new Address();
Person person = new Person(address);

or

Person person = new Person( new Address() );

As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.

Tutorial 1-UML Diagram:Use case

This tutorial provides a quick introduction to the Unified Modeling Language.
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
1.Use case diagrams
2.Class diagrams
3.Object diagrams
4.Sequence diagrams
5.Collaboration diagrams
6.Statechart diagrams
7.Activity diagrams
8.Component diagrams
9.Deployment diagrams

The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model.
A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes.
Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity. Objects are instances of classes.

1.Use case diagrams
Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic.

Scenario :"A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "
A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).



Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.

A use case diagram is a collection of actors, use cases, and their communications. We've put Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use case can have multiple actors.

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

The Microsoft Best Practices Analyzer for Microsoft Windows SharePoint Services 3.0 and the 2007 Microsoft Office System creates detailed reports to help administrators achieve greater performance, scalability, and uptime.

Microsoft Best Practices Analyzer for Windows SharePoint Services 3.0 and the 2007 Microsoft Office System

Design patterns

Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.

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

Application Architecture

Application Architecture Guide Book for Microsoft .Net Patterns

The purpose of the Application Architecture Guide 2.0 is to improve your effectiveness building
applications on the Microsoft platform. The primary audience is solution architects and
developer leads. The guide will provide design-level guidance for the architecture and design of
applications built on the .NET Platform. It focuses on the most common types of applications,
partitioning application functionality into layers, components, and services, and walks through
their key design characteristics.

Application Architecture Guide Book for Microsoft .Net Patterns and Practise V2.0 is Released

Download Book Application Architechture Guide V2.0

PartsPart I,
Fundamentals Part II,
DesignPart III,
LayersPart IV,
Archetypes

Chapters
Introduction
Architecture and Design Solutions At a Glance
Fast Track
Part I, Fundamentals
Chapter 1 - Fundamentals of Application Architecture
Chapter 2 - .NET Platform Overview
Chapter 3 - Architecture and Design Guidelines
Part II, Design
Chapter 4 - Designing Your Architecture
Chapter 5 - Deployment Patterns
Chapter 6 - Architectural Styles
Chapter 7 - Quality Attributes
Chapter 8 - Communication Guidelines
Part III, Layers
Chapter 9 - Layers and Tiers
Chapter 10 - Presentation Layer Guidelines
Chapter 11 - Business Layer Guidelines
Chapter 12 - Data Access Layer Guidelines
Chapter 13 - Service Layer Guidelines
Part IV, Archetypes
Chapter 14 - Application Archetypes
Chapter 15 - Web Applications
Chapter 16 - Rich Internet Applications (RIA)
Chapter 17 - Rich Client Applications
Chapter 18 - Services
Chapter 19 - Mobile Applications
Chapter 20 - Office Business Applications (OBA)
Chapter 21 - SharePoint Line-Of-Business (LOB) Applications
Appendix
Cheat Sheet - patterns & practices Pattern Catalog
Cheat Sheet - Presentation Technology Matrix
Cheat Sheet - Data Access Technology Matrix
Cheat Sheet - Workflow Technology Matrix
Cheat Sheet - Integration Technology Matrix