Design Patterns in the Wild

Design patterns are often presented as standard solutions that can be used to commonly occurring problems. I think that it is equally important to be able to recognize patterns in existing code. Being able to identify a pattern helps understanding the code better. It also helps rising the abstraction level. It can be used to describe the architecture of a system without having to describe each part in detail.

The architecture is Transaction Script based. The transaction scripts are located in the Logic namespace. The same classes are used both as Data Transfer Objects and as Query Objects. A custom Object-Relational Mapper is used for database access.

Without the patterns as a common basis for communication the same description would be considerably longer.

Let’s have a look at some patterns in C# development.

One of the most basic patterns is the Observer Pattern. In C# it is built into the language. A common task is to hook up an event handler, e.g. in an ASP.NET page.

protected void Page_Load(object sender, EventArgs e)
{
    SomeButton.Click += SomeButton_Click;
}
 
protected void SomeButton_Click(object sender, EventArgs e)
{
    Response.Redirect("AnotherPage.aspx");
}

In this code the button is the subject being observed by the page. The observer pattern is built into the language.

Another example in the .NET environment is the LINQ to SQL data context.

using(DBContext context = new DBContext())
{
    var query = from p in context.Persons
                where p.ID = personID
                select p;
 
    Person person = query.Single();
 
    person.Active = true;
 
    context.SubmitChanges();
}

In this short piece of code, three different patterns are present. The DBContext is a Repository. It is an object-oriented representation of the database model. To query from the database a query object is created. It is created using built in language support for queries through LINQ. The last pattern is Unit of Work, that keeps track of changed objects and writes them to the database. It is the DBContext that is the unit of work, so that class has dual roles – it is both a Repository and a Unit of Work. In real code this is quite common with the same class participating in different patterns, with different roles in each pattern.