Design Patterns C#

Day of Patterns & Practices Tomorrow - Tampa, Florida RoadShow

Dave Hayden — Wed, 30 Jan 2008 10:02:00 GMT

Looking forward to seeing everyone at the Day of Patterns & Practices Event tomorrow in Tampa!

Presentations include:

Web Client Software Factory v2.0
Web Service Software Factory: Modeling Edition
TDD and Model-View-Presenter
ASP.NET MVC Framework

Software Development Tip: Avoid Race Conditions Using Tester-Doer Pattern

Dave Hayden — Wed, 26 Sep 2007 21:49:00 GMT

One of the patterns that came up today in a code review was the Tester-Doer Pattern. One sees this pattern a lot especially when the “doer” side of the equation has a pretty decent performance penalty. Essentially, you test a condition to make sure you need to do the “doer“ operation and pay that penalty. Sometimes this can cause race conditions. Read more...

Chain of Responsibility Pattern - Builder Pattern - Fluent Interfaces

Dave Hayden — Wed, 19 Sep 2007 16:21:00 GMT

Using the Chain of Responsibility Pattern, Builder Pattern, and Fluent Interfaces to find the appropriate constructor to inject dependencies into as part of the sample Dependency Injection Application Block I created using the Application Block Software Factory in Enterprise Library 3.1. Read more...

Model View Presenter Pattern - User Interface Design Patterns

Dave Hayden — Wed, 13 Sep 2006 17:27:00 GMT

Model-View-Presenter Pattern - User Interface Design Patterns

by David Hayden ( ASP.NET Developer )

I was reading a few blog posts today and noticed that Scott Cate gave a presentation on the Model View Presenter Pattern at the Florida.NET User Group. According to his post, it looks like he rocked the house. I am envious here in Sarasota, wishing I could have seen the presentation for which he provided the source code.

Still, I feel like I was there, because I downloaded the source code to see what he had built from scratch during the presentation. If you are new to the Model View Presenter Pattern and looking for a gentle introduction to it, I highly recomment looking at the source code. Scott uses table adapters for data access and uses the ASP.NET Page as the view. Simple and straight forward without adding a lot of extra fat to make the subject more complex than it has to be. Great job, Scott. Maybe we can get you to Sarasota for a similar presentation.

I played with Scott's source code a bit, evolving it into something that I could unit test. This isn't necessary, but I enjoyed the exercise :) Right now as the Presenter class stands, it is tied directly to the table adapter that retrieves data:

namespace MiramarFAQ.Presenter
{
    public class RetrieveFaqPresenter
    {
        private readonly IRetrieveFaqView view;
        
        public RetrieveFaqPresenter (IRetrieveFaqView view)
        {
            this.view = view;
        }
        
        public void RetrieveFAQ()
        {
            FaqTableAdapter adapter = new FaqTableAdapter();
            DataTable faq = adapter.GetDataByFaqId( view.FaqId );
            
            //...
        }
    }
}

I changed the Presenter code a bit so it looked like this:

namespace MiramarFAQ.Presenter
{
    public class RetrieveFaqPresenter
    {
        private readonly IRetrieveFaqView view;
        private readonly IFaqDataService service;

        public RetrieveFaqPresenter(IRetrieveFaqView view) :
            this(view, new SqlFaqDataService()) { }

        public RetrieveFaqPresenter(IRetrieveFaqView view,
                                     IFaqDataService service)
        {
            this.view = view;
            this.service = service;
        }

        public void RetrieveFAQ()
        {
            DataTable faq = service.GetDataByFaqId(view.FaqId);
            
            //...
        }
    }
}

All I have done is introduced an IFaqDataService as a dependency to the presenter as oppose to hardcoding the TableAdapter in the code. This gives me a bit more pluggability of the data access layer as well as offers more testability.

namespace MiramarFAQ.Data
{
    public interface IFaqDataService
    {
        DataTable GetDataByFaqId(int FaqId);
    }
}

namespace MiramarFAQ.Data
{
    public class SqlFaqDataService : IFaqDataService
    {
        #region IFaqDataService Members

        public DataTable GetDataByFaqId(int FaqId)
        {
            FaqTableAdapter adapter = new FaqTableAdapter();
            return adapter.GetDataByFaqId(FaqId);
        }

        #endregion
    }
}

Now that we have introduced a dependency on only an interface, IFaqDataService, in the presenter class, we can create a stub for our unit testing:

public class StubbedFaqDataService : IFaqDataService
{
    #region IFaqDataService Members

    public DataTable GetDataByFaqId(int FaqId)
    {
        Faq.FaqDataTable dt = new Faq.FaqDataTable();
        dt.AddFaqRow("Title", "Body", "Author", "tag1,tag2",
               "testing...", DateTime.Now);
        return dt;
    }

    #endregion
}

I won't bore you with details of the unit tests, but you can see where all of this takes you. You lose that dependency on TableAdapters, and focus your dependency on an interface ( contract ), called IFaqDataService. This opens the doorway for pluggable data access services, dependency injection, and unit testing.

Again, I wish I could have been there for Scott's presentation on Model View Presenter, because the code only tells half of the story. I bet the dialogue was fantastic. Thanks to all the INETA speakers who devote time to helping the community. Thanks to Scott for sharing his code so I could vicariously be there via Sarasota, Florida. Don't forget to check out Scott's source code.

Other Resources

In addition to Scott Cate's wonderful example, here are a number of great articles by some very smart people:

Source: David Hayden ( ASP.NET Developer )

Filed: Design Patterns

Contract-First-Design and Dependency Injection ( Microkernel )

Dave Hayden — Tue, 05 Sep 2006 19:00:00 GMT

Contract-First-Design and Dependency Injection ( Microkernel )

by David Hayden ( Florida .NET Developer )

A few weeks ago I talked about Dependency Injection Tools as a way to remove service locator and factory classes from my code:

Dependency Injection Tools and Inversion of Control - Applying Domain-Driven Design and Patterns

Although I have heard of dependency injection, inversion of control, and other related topics for some time, that was my first time using a dependency injection tool to provide the loose-coupling desired in many of my applications.

Today I had a chance to read a blog post by Ralf Sudelbücher, entitled Dynamic component binding made easier - An easy to use Microkernel to help reap Contract-First-Design benefits in .NET programs. Ralf describes the use of a Microkernel ( depedency injection like ) as a means to support Contract-First-Design. I think the post is excellent and worth the time to read if you need or would enjoy a primer on dynamic binding of concrete services that implement contracts.

I, honestly, didn't know what Contract-First-Design meant until I read Ralf's post. He mentioned it as such:

“CFD views software as consisting of components. To avoid any heated discussion on what this term could possibly mean, let me try a very practical explanation: Think of a component as an assembly or a set of related assemblies. This assembly (or set of assemblies) you want to use together with other components to build a software solution.“

he further mentions the following:

“... So just think: Components encapsulate some functionality I want to separate from other functionality in other components.“

Dependency-Inversion Principle

Sounds like I have been using Contract-First-Design for quite some time, because it is essentially good use of the Dependency-Inversion Principle in object-oriented programming as I discuss in the following post:

The Dependency-Inversion Principle - Chapter 11 - Agile Software Development Principles Patterns and Practices

The Dependency-Inversion Principles states that:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

If you look at the code I just mentioned in the previous post, Active Record To Domain Objects and Data Access Objects - Data Access Design Patterns, and shown below, you will see that my CustomerDAO is not dependent on a concrete class that implements IDatabase, but the contract IDatabase. CustomerDAO itself implements a contract, ICustomerDAO, that is consumed by a client that uses the ICustomerDAO service - yet has no clue the concrete class, CustomerDAO, exists or will be the provider of the service.

You can get crazy with this loose-coupling if it is based upon “speculative design“ and you are adding extension points where no extension is necessary, but in general, loose-coupling and Contract-First-Design is a nice quality in your applications. As Ralf so eloquently puts it, it allows you to develop components independent of one another in parallel as well as offers great testability through mocks and stubs.

public class CustomerDAO : ICustomerDAO
{
    private IDatabase _database;
    
    public CustomerDAO()
    {
        _database = DatabaseFactory.CreateDatabase();
    }
    
    public CustomerDAO(IDatabase database)
    {
        Validation.AssertIsNotNull(database);
        _database = database;
    }
    
    public Customer FindById(...)
    {
        ...
    }
    
    public int Save(Customer customer)
    {
        ...
    }
    
    public int Update(Customer customer)
    {
        ...
    }
    
    public int Delete(Customer customer)
    {
        ...
    }
    
    public Customer FindByEmailAddress(...)
    {
        ...
    }
    
    public CustomerCollection FindByState(...)
    {
        ...
    }
}

Source: David Hayden ( Florida .NET Developer )

Filed: Design Patterns

O/R Mapping Caching for Performance vs. Uniquing ( Identity Map Design Pattern )

Dave Hayden — Tue, 05 Sep 2006 11:38:00 GMT

Frans writes a great post about Why a cache in an O/R mapper doesn't make it fetch data faster. In fact, depending on how the cache is used, it could actually degrade performance as the management of the cache plays a factor in the performance of the O/R Mapper.

Frans mentions that the O/R Mapper's cache may not be so much about performance as it is about uniquing. Martin Fowler in Patterns of Enterprise Application Architecture refers to uniquing as the Identity Map Object-Relational Behavioral Pattern - “Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.”

The idea here is that multiple requests for the same database entity in a given context refer to the same object in memory. Therefore if I ask for the same Customer multiple times in the same context, the customer will only be retrieved once from the database and placed in an identity map. Future requests for the same customer in the same context will pull the customer from the identity map ( usually a hash table ) and not from the database. In general uniquing is referred to as a good thing, but future requests for old, stale data from an identity map in a given context may not be desirable in your application.

Frans does a much better job explaining caching in O/R Mappers with another must read post.

Source: David Hayden ( Sarasota Web Design )

Filed: O/R Mappers, Design Patterns

Active Record To Domain Objects and Data Access Objects - Data Access Design Patterns

Dave Hayden — Fri, 01 Sep 2006 14:48:00 GMT

Active Record To Domain Objects and Data Access Objects - Data Access Design Patterns

by David Hayden ( Florida .NET Developer )

In my previous post

Active Record Design Pattern Doesn't Require Static Finder Methods

I discussed the fact that the Active Record Design Pattern doesn't require static finder methods for encapsulating common SQL queries to return one or more active record objects. One could move those static finder methods to a separate class, such as CustomerFinder, mentioned here again from the previous post:

public class CustomerFinder : ICustomerFinder
{
    private IDatabase _database;
    
    public CustomerFinder()
    {
        _database = DatabaseFactory.CreateDatabase();
    }
    
    public CustomerFinder(IDatabase database)
    {
        Validation.AssertIsNotNull(database);
        _database = database;
    }
    
    public Customer FindById(int id)
    {
        ...
    }
    
    public Customer FindByEmailAddress(...)
    {
        ...
    }
    
    public CustomerCollection FindByState(...)
    {
        ...
    }
}

To each their own, but IMHO this is rather undesirable, because when a change occurs in the database we now need to change the persistence logic in 2 classes: 1) The Active Record Class which has read and write SQL capabilities, and 2) The Finder Class which handles SQL finder queries. You will also end up probably having 2 base classes or more (instead of a single layer supertype ) to refactor common code from the various active record and finder classes.

Data Access Objects

If static methods using active record is a problem, then the answer is not to go half-way and create Finder Classes, but to move to Data Access Objects (DAO). DAO does nothing more than separate the persistence logic for a class into a separate class. All persistent logic in the Active Record and Finder Classes gets moved to a class that is responsible for all data access needs for the class, leaving the original class with only data and domain logic behavior. The CustomerDAO Class doesn't look much differently from the CustomerFinder Class actually. It has just accepted additional behavior that was in the Customer Class:

public class CustomerDAO : ICustomerDAO
{
    private IDatabase _database;
    
    public CustomerDAO()
    {
        _database = DatabaseFactory.CreateDatabase();
    }
    
    public CustomerDAO(IDatabase database)
    {
        Validation.AssertIsNotNull(database);
        _database = database;
    }
    
    public Customer FindById(...)
    {
        ...
    }
    
    public int Save(Customer customer)
    {
        ...
    }
    
    public int Update(Customer customer)
    {
        ...
    }
    
    public int Delete(Customer customer)
    {
        ...
    }
    
    public Customer FindByEmailAddress(...)
    {
        ...
    }
    
    public CustomerCollection FindByState(...)
    {
        ...
    }
}

This is a trivial example and DAO objects will vary, but I think it shows the point. You will probably end up with a layer supertype for the domain layer and the data access layer for refactoring common code, etc:

public class CustomerDAO : DAOBase, ICustomerDAO
{
    ...
}

public class Customer : BusinessBase
{
    ...
}

Conclusion

If ActiveRecord Static Finder Methods are troublesome, you could create a Finder Class for each domain object. IMHO the effort is not worth the headache. Move to Data Access Objects and leave your domain objects persistent ignorant.

Source: David Hayden ( Florida .NET Developer )

Filed: Design Patterns

Active Record Design Pattern Doesn't Require Static Finder Methods

Dave Hayden — Fri, 01 Sep 2006 11:21:00 GMT

Active Record Design Pattern Doesn't Require Static Finder Methods

by David Hayden ( Sarasota .NET Developer )

The Active Record Design Pattern that I have talked about in a few posts:

describes an object that encapsulates a row in a database table or view. The object has the ability to read and write itself to the datastore as well as contains domain logic. As I mentioned in the previous Active Record Posts, it is most successful with forms-over-data applications, where you have simple business rules and the database model is the domain model. For these types of projects you will use some type of code generation and/or O/R Mapper to generate the classes for you, which contain mostly data access code.

For convenience, you will often find Static Finder Methods on these classes to wrap common queries that return Active Record Objects. I say convenience, because it has become a common practice to use static finder methods. Static finder methods on the class will probably be the first place a developer will look to find such functionality when you tell them you are using the Active Record Design Pattern.

However, you don't need to use static finder methods. You could use a separate class. Hence, you could have a Customer Class and a CustomerFinder Class. The Customer Class would represent a single row in a database table that can read and write itself to the datastore. When you want to find a customer or a collection of customers, you could execute instance methods on the CustomerFinder Class.

public class CustomerFinder : ICustomerFinder
{
    private IDatabase _database;
    
    public CustomerFinder()
    {
        _database = DatabaseFactory.CreateDatabase();
    }
    
    public CustomerFinder(IDatabase database)
    {
        Validation.AssertIsNotNull(database);
        _database = database;
    }
    
    public Customer FindById(int id)
    {
        ...
    }
    
    public Customer FindByEmailAddress(...)
    {
        ...
    }
    
    public CustomerCollection FindByState(...)
    {
        ...
    }
}

Whether you want to create a separate finder class is up to you. My only point is that Active Record does not require you to have static methods. It is pure convenience. If the static methods get in your way, move them to a separate class.

Source: David Hayden ( Sarasota .NET Developer )

Filed: Design Patterns

Dependency Injection Tools and Inversion of Control - Applying Domain-Driven Design and Patterns

Dave Hayden — Fri, 21 Jul 2006 13:16:00 GMT

Dependency Injection Tools and Inversion of Control - Applying Domain-Driven Design and Patterns

by David Hayden ( Sarasota Web Developer )

Kudos to Erik Dornenburg, who finally made the light go off in my thick brain as to the value of Dependency Injection Tools. Erik is a guest author in Jimmy Nilsson's new book, Applying Domain-Driven Design and Patterns, and he wrote the most excellent chapter, called Inversion of Control and Dependency Injection. Here is how it happend :)

Service Locators and Factories

During some down time this week I started updating some CodeSmith Templates that create an administrative backend to a database. The templates work fine, but I thought I would update them to use ASP.NET Master Pages and Generics. While going through the code, I came across my typical use of Service Locator and Factory Classes that offer a bit of loose coupling and testability of the data access code. Here is an example of the Factory Class, for example, that creates the Data Access Objects used in the application:

public class DAOFactory
{
    public static T Create<T>()
    {
        IDatabase db = Registry.Fetch<IDatabase>();
        T dao = Registry.Fetch<T>();
        dao.Database = db;
        return dao;
    }
}

You would use the code like this:

ICustomerDAO dao = DAOFactory.Create<ICustomerDAO>();

The Registry Class used in the Factory is essentially a Service Locator. The Service Locator reads a name-value collection of concrete classes at runtime that implement the services needed by the application. Thus, when you call

Registry.Fetch<ICustomerDAO>();

it is essentially retrieving the concrete class that implements ICustomerDAO, which is set in the configuration file or changed at runtime. More than likely this will just be CustomerDAO :)

Additionally, the Data Access Objects are dependent on an IDatabase Class, which is responsible for the actual database calls and specific for each database. Although in this case I have only written one class that implements IDatabase, SqlServerDatabase, the idea is that you could have versions for Oracle, MySql, etc. This IDatabase dependency gets injected into the DAO via a setter in the Factory Class as mentioned above:

IDatabase db = Registry.Fetch<IDatabase>();
T dao = Registry.Fetch<T>();
dao.Database = db; // Inject Dependency

All of this is pretty standard use of good object-oriented principles and design patterns to keep your application loosely-coupled, offer testability, and provide pluggability. But, this is stuff I don't really need to do, because Dependency Injection Tools already do this for me and do a better job - DOH!

Dependency Injection Tools

Around the same time that I started updating the CodeSmith Templates, I also promised myself that I would look at Jeremy Miller's StructureMap that he has been talking about off and on via his blog. My reason for doing so was mainly to better understand what he felt so passionate about to create and talk about in several posts. As it happens, StructureMap just happens to be a Dependency Injection Tool, one of several for the .NET Framework.

Now the concept of Dependency Injection is not new, although I seem to hear it more and more these days. It essentially means that objects don't go out and get other objects that they depend upon; instead the dependent objects are given ( injected ) to them. The perfect example is my DAOFactory above. The Data Access Object doesn't go out an get the IDatabase Service it is dependent upon, I populate it via a property setter in the Factory.

dao.Database = db; // Inject Dependency

This is great for testability, because normally when I build and test these classes I will create test stubs that read data from an xml file, for example, so that I am not dependent on a database or other external process.

Now what I had not realized is that a Dependency Injection Tool is essentially a Service Locator and Factory in one. Either during runtime or in a configuration file, you can specify all the services ( StructureMap calls these Plug-In Families ) and their concrete implementations ( Plug-Ins ) and their dependencies.

By using StructureMap, I can remove my Factory and Service Locator Classes completely from the application. I map the services and dependencies in a separate configuration file, called StructureMap.config, and one call does everything:

ICustomerDAO dao = (ICustomerDAO)ObjectFactory.
                  GetInstance(typeof(ICustomerDAO));

Behind the scenes, StructureMap finds the appropriate implementation of ICustomerDAO and injects it with the appropriate implementation of IDatabase which is also injected with the appropriate connection string. It's a thing of beauty and I feel really late to the show :)

Conclusion

If you haven't embraced a Dependency Injection Tool in your application, I highly recommend doing so. It makes your applications far more loosely coupled and avoids one from having to wire up all this stuff yourself using Factories, Registries, and Service Locators.

By no means am I pushing StructureMap. There are other tools for the .NET Framework: Spring.NET, Castle Windsor, ObjectBuilder, etc. I've downloaded a number of them and will be trying them out in the upcoming weeks.

Resources:

Source: David Hayden ( Sarasota Web Developer )

Filed: Design Patterns, .NET Tools

Agile Principles, Patterns, and Practices in C# by Robert Martin

Dave Hayden — Mon, 03 Jul 2006 23:34:00 GMT

I just got back from a long and much needed vacation. While spending most of the day trying to make a dent in my Inbox, I came across an email from Amazon mentioning a new book from Robert Martin, called Agile Principles, Patterns, and Practices in C#...