Building loosely coupled application architectures requires more than just separating your application into different layers.

In this article, I’ll take a project that was built using techniques that result in fragile, hard-to-test code and introduce some principles, techniques, and refactorings that will help you realize flexibility and testability in your applications.

Most developers understand the value of the layered approach to architecture. The main principle behind layered architectures is that of “separation of responsibility”. Each layer is responsible for a finite amount of work. Any work that cannot (read should not) be done by a particular layer gets delegated to a layer more appropriate for handling the task.

Unfortunately, people using layered architectures can often run into a scenario where they introduce an unnecessary amount of coupling between layers of their application. A high degree of coupling is one factor that can lead to fragile application architectures that are difficult to change or extend.

The first part of this article deals with introducing a design principle that will enable you to take advantage of layered architectures in a much cleaner fashion, and then demonstrates how introducing dependency injection into the mix can help you realize your goals for pluggable application architectures.

The Case at Hand

Assume for a moment that Figure 1 is a screen that I am developing for viewing information on Employees that work with my company. Being that it’s such a “simple” screen, I dive in and quickly hammer out the code shown in Listing 1. (In case anyone asks, I would never do this!)

Figure 1: This looks like a pretty simple screen to build, right?

I’ll pause for a second to allow the utter travesty of that code to truly sink in! The code breaks several application architecture rules:

• Hard-coded connection strings.
• User interface has intimate knowledge of database tables.
• User interface is responsible for mapping database data into domain objects.
• Coding to implementations not abstractions.
• Forget about that last bullet point for a little while. I can start to remedy the first three items by introducing a layered application architecture.

Separating Responsibilities with a Layered Architecture

One of the main issues with the code in Listing 1 is that it takes the single responsibility principle and throws it completely out of the window. The single responsibility principle simply states that “every object should have a single responsibility and therefore only a single reason to change.” If you are already familiar with the term cohesion, you can quickly identify that a component that follows this principle can often be described as a “highly cohesive” component.

If I took a moment to ask the question, “What should the main responsibility of the View Employees Web page be”? The simple answer is that it should only be dealing with the rendering of a set of employees to the user. However, if I take a look at the code-behind, the reality of the situation is quite different. Instead of methods focused around the rendering of employees to the user, the component is currently responsible for:

• Creating a connection to the database.
• Creating a SQL statement to pull the appropriate information from the database.
• Disposing of expensive resources (connection, reader, etc.).
• Mapping the database information to a domain representation of the data.
• Rendering the information to the user.

As you can see from this short list, this component has far too many responsibilities. To make matters worse, not all (most) of the responsibilities have anything to do with “rendering” a list of employees to the user. If this does not smell of low cohesion, I don’t know what does.

For a long time people have been realizing the value of introducing the concept of n-tier/layered architectures into their applications to address this very issue. In short, the introduction of a layered architecture can ensure that each layer (as pragmatically as possible) can adhere to the single responsibility principle. Figure 2 shows a proposed high-level diagram for the separate layers that will make up the application. I am going to tackle refactoring this application by going from the top down. I can first make use of the “passive view” variant of the “model view presenter” design pattern to deal with the abuse of responsibility in the code-behind for the Web page. I will not dive into the details of this pattern in this article; you can take a look at an article I wrote last year that talks about the pattern in more detail: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/)

Figure 2: A proposed high-level diagram for the separate layers.

The first refactoring I will tackle is to pull out code not directly related to the responsibility of “rendering employees” (read: pull pretty much all code from the code-behind!). Listing 2 shows the resulting code for the code-behind of the Web page. Compared to Listing 1, the difference here is night and day. If you are not familiar with the passive view pattern, here’s a quick description:

• View implementation (Web page) implements an interface that is consumed by the presenter.
• The View interface exposes events that are implemented by the View (Web page) and subscribed to by the presenter.
• The View raises events in response to events that occur on itself (for example, Button is clicked, Load is happening), these events are in turn handled by the presenter.
• The presenter processes the event accordingly and may push information back to the view by means of using the View interface.
• Using the View interface allows the presenter to remain loosely coupled to any particular UI technology (for example, ASP.NET).

Listing 3 shows the first iteration of the presenter class.

From the looks of Listing 3 all that I have managed to accomplish is to push the messiness that was originally located in the code-behind for the Web page and move it into another class. However, with the introduction of the interface for the view, I have introduced a concept that is critical in creating flexible layered architectures: the dependency inversion principle.

The Dependency Inversion Principle

As I mentioned, I stealthily slipped in the addition of this principle by introducing the passive view pattern-in particular, an interface (abstraction) for the view. The code for the View interface is as follows:

    public interface IEmployeeView
    {
        event EventHandler Load;
        bool IsPostBack { get; }
        IList<IEmployee> Employees {
                          set; }
    }

Pretty simple. Notice that the Load event is defined on the View interface, but you probably did not see an explicit implementation in the code-behind for the Web page. This is because all Web pages already define a Load event (with the same delegate signature), which satisfies the requirements of the interface. The same goes for the IsPostback property (already satisfied by the Page class). Why the introduction of an interface? By coding to an interface (or an abstraction), the presenter can now talk to any object that implements this interface, whether it is a Windows Form, a mobile Web control, or a Web page. The presenter does not care about the actual implementation because it will always be talking to that implementation through an abstraction-the interface. This point demonstrates and introduces the importance of the dependency inversion principle, which can be described simply as:

“High-level components should not depend on low-level components; they should both depend on interfaces.”

I will take that principle and utilize it to further clean up the code in the presenter.

I can now safely forget about the Web page and its accompanying code-behind as it will remain static for the remainder of the refactorings. Again, this speaks to the beauty of layered architecture and its ability to allow me to radically enhance the code without causing unnecessary ripple effects. In switching focus to the presenter, I am going to treat it as the “high level” component. What low-level components does it currently depend upon? The following code snippet should give you a couple of clues:

using (connection = new 
SqlConnection(ConnectionString))
   {
       SqlCommand command = 
       connection.CreateCommand();
       command.CommandText = 
       "SELECT * FROM Employees";
       command.CommandType = 
       CommandType.Text;

       connection.Open();

     using (SqlDataReader 
        reader = command.
        ExecuteReader(CommandBehavior.
        CloseConnection))
       {
           DataTable results = new 
           DataTable();
           results.Load(reader);
           return results;
       }
   }

In this section of code I am coupling the presenter to SqlConnection, SqlCommand, and SqlDataReader objects. In reality, worse than the coupling is the fact that this functionality does not really belong in the presentation layer of a project. Why? It still unnecessarily couples my presentation layer to the underlying physical database that is serving data to this application.

How can I address this problem? As the old computer-science axiom quotes, “Another layer of indirection will solve any problem.” I am going to clean up the code in the presenter by adding a service layer to the project. For a detailed description of what a service layer is you can read the following article: http://www.martinfowler.com/eaaCatalog/serviceLayer.html. In the context of this article, all you need to focus on is that I am using the service layer as a façade to shield the presentation layer from the details of executing application functionality (in this scenario, retrieving a set of employees). I am going to utilize dependency inversion to come up with a contract (abstraction) for a service-layer component that will provide me the ability to “Get All Employees.”

Examining the presenter closely, I can identify that its main role is to provide the View with a list of employees. It should not matter how that list is retrieved-that falls into the realm of the service layer (ultimately a mapper layer, but I’ll omit talking about that in this article). With the main role identified, I come up with an interface for the service-layer component that the presenter will talk to:

    public interface IEmployeeTask
    {
        IList<IEmployee> 
        GetAllEmployees();
    }

Yes, it’s that simple. Again, following the dependency inversion principle leads me to believe that the presenter now has more than just a dependency on the View. Prior to the introduction of the service layer, the presenter was responsible for work that will (eventually) be pushed down into a service layer. The beauty of coding to abstractions is that all the presenter has to talk to is a contract. At compile time the presenter does not know (or care) whether that contract is implemented. This allows me to complete the code for my presenter without the need for an actual concrete implementation of the service-layer component to even exist. Listing 4 shows the presenter that has been refactored with the introduction of a dependency on a lower-layer component.

This cleans things up considerably. By utilizing the dependency inversion principle I have refactored the presenter into a much more highly cohesive unit. It is responsible for pushing data to the view (by means of an interface); and it retrieves the data from a service-layer component, that it also talks to using a contract (interface). In completing the refactoring for the presenter, I also quietly snuck in a new technique that makes utilizing dependency inversion all the more appealing: dependency injection.

Dependency Injection

If you take a closer look at Listing 4 you will see something very important happening in the constructor of the presenter:

public 
  ViewEmployeesPresenter(IEmployeeView
  view, IEmployeeTask task)

Even though the presenter has its own cohesive set of responsibilities, it cannot accomplish its responsibilities without leaning on its dependencies. It just so happens that its dependencies are provided to it at the time of creation. This is a type of dependency injection called constructor-based dependency injection.

The main idea behind dependency injection is that if an object has reliance on other “components” to help it accomplish its work, it should not be responsible for creating those components; rather, the components it depends on should be injected into it in the form of abstractions.

The two most popular types of dependency injection are: constructor injection and setter injection

In constructor injection, the object with dependencies is provided all of its dependencies at the time of instantiation. It does not matter who creates it-it has to be given all that it needs to do its job. If it is not provided with all that it needs (read: null is passed in as a dependency), the object should not be expected to be able to complete its work. The one disadvantage to constructor-based injection is that it can get a little unwieldy if the object has a lot of dependencies that it needs to be constructed with (of course, this could be shielded by the use of a factory).

Setter injection uses a slightly different technique and almost always relies on a factory to create the object and wire it up with its dependencies. In setter injection there is no special constructor on the object with dependencies. All of its dependencies are injected to it by the factory through setter properties that the object exposes for the dependencies it needs. A disadvantage of setter-based dependency injection is that if you omit the use of a factory you may unnecessarily couple components that use the object to the implementations of the dependencies the object requires.

The whole concept of dependency injection hinges around the concept of programming to abstractions. In this scenario the presenter has a dependency on:

• A “view” that can render the information that is pushed to it.
• A “service” that can execute application functionality on behalf of the presenter.

From a testability perspective, utilizing both dependency inversion and dependency injection allows for an increased level of testability as well as lower coupling between components of an application. In the following code, I demonstrate how to utilize a combination of unit testing and mock objects to verify that when the presenter is constructed it subscribes to the Load event on the View interface:

[Test]
public void 
ShouldSubscribeToViewEventsOn
  Construction()
{
    MockRepository mockery = new 
    MockRepository();
    IEmployeeView mockView = mockery.
    CreateMock<IEmployeeView>();
    IEmployeeTask mockTask = mockery.
    CreateMock<IEmployeeTask>();

    mockView.Load += delegate { };
    LastCall.IgnoreArguments();
    mockery.ReplayAll();

    ViewEmployeesPresenter presenter =
    new ViewEmployeesPresenter(
    mockView, mockTask);
    mockery.VerifyAll();
}

I am making use of a mock object framework called Rhino Mocks and the NUnit unit testing framework. (As a practitioner of TDD, I would usually write this test first to drive out the functionality of the presenter. I chose for this article to not cloud the topic with another conversation about TDD!) You can find the accompanying code that makes this test pass in the presenter class itself:

public ViewEmployeesPresenter(
   IEmployeeView view, IEmployeeTask 
   task)
{
    this.view = view;
    this.task = task;

    HookupEventHandlersTo(view);
}

private void HookupEventHandlersTo(
IEmployeeView view)
{
    view.Load += delegate {
    LoadEmployees(); };
}

Notice that in the constructor a call is made to the HookupEventHandlersTo method which in turn subscribes to the Load event defined by the View interface.

From a maintainability perspective I now have a guaranteed way of ensuring that whenever the presenter is constructed that it subscribes to the Load event on the view. Of course, the actual functionality comes when the Load event on the view is triggered. This is where the presenter can communicate to the service layer and request a list of all employees, which it then pushes back to the view. Yet again, leveraging dependency injection allows me to easily write a test for this scenario. And again, I can substitute mock objects in place of “real” objects and the presenter is none the wiser because it is dependent on abstractions, not implementations.

Of course, the presenter has been relegated to nothing more than a component that acts on and reacts to its dependencies. The component that the presenter consumes seems to be the place where all the action should be happening. I’ll drill down into the service layer and show how you can apply the techniques of dependency inversion and dependency injection to create a clean implementation of the IEmployeeTask interface.

Putting Dependency Injection and Dependency Inversion through Their Paces in the Service Layer

Listing 5 shows all of the code that I stripped from the presenter that seems to have gone the way of the Dodo bird. I can address that by creating an implementation of the IEmployeeTask interface in the service layer. Listing 6 shows my first take at an implementation of the service. This can’t be right. I did so much work to clean up my UI and presenter only to come down to the service layer and duplicate the mistakes that started me down this path in the first place? Armed with the new knowledge I have about dependency inversion and dependency injection I can now clean up the dependency on implementations rather than abstractions. I’ll start by introducing a new interface into the mix:

public interface IConnectionFactory
    {
      IDbConnection Create();
    }

With the IConnectionFactory interface created I can use dependency injection to ensure that the service layer class is constructed with an IConnectionFactory:

public EmployeeTaskLowCohesion
NoDependencyInversion(
ConnectionFactory 
connectionFactory)
{
    this.connectionFactory = 
    connectionFactory;
}

With that small change in place it allows me to change the code in the GetEmployees method to what is shown in Listing 7. Notice that the GetEmployees method is no longer coding to explicit SqlClient implementation; it is now coding to abstractions defined in the System.Data namespace. This (with a little work) could allow this component to seamlessly work with any database. The only differentiator would be the implementation of IConnectionFactory that would have to be plugged in to create a connection bound to a particular database (Oracle, SQL, MySQL, etc.). Again, another positive side-effect of this style of coding is that it allows me to easily test the behavior of this class without actually pointing it at a real database.

Does this mean that I am done with the current implementation of IEmployeeTask? Absolutely not. In my opinion, the current implementation has too many responsibilities which should be placed in other objects (even completely different layers). Rather than drill down into more abstractions, I would rather spend the remainder of this article discussing the wiring up of all of these dependencies to one another. You can look at the code that accompanies this article to get an idea of how I cleaned up the service layer class, as well as separated responsibilities into more discrete layers.

Gluing It All Together

With all of these abstractions and dependencies being injected left, right, and center, some of you might be asking the question, “Who injects the dependencies?” I’ll revisit the presenter and the accompanying Web page. Remember the constructor for the presenter:

public ViewEmployeesPresenter(
IEmployeeView view, IEmployeeTask 
task)

I can’t construct the presenter without giving it both the view it is working with and the service layer it makes requests of. This poses a problem for me because the code-behind for the Web page needs to instantiate the presenter that will work with it (there are other solutions to this that are outside the scope of this article):

presenter = new 
ViewEmployeesPresenter(this);

This would be fine if the presenter only had a dependency on the view. Unfortunately, it does not. The presenter has to have both of its dependencies satisfied at the time of creation. A quick way to solve this problem would be to add a reference from the Web project to the service layer project, and then do this in my code-behind for the Web page:

presenter = new 
ViewEmployeesPresenter(this, new 
EmployeeTask());

Unfortunately, this causes the view to not just be responsible for creating its presenter, it also now has to create and be coupled to the dependencies the presenter is reliant on. That seems to defeat the purpose of going down this road in the first place.

You can solve this problem in a multitude of ways starting from simplistic and “coupled” to more involved and loosely coupled. I’ll start off by examining the simplistic approach.

I want to ensure that the only thing the Web page needs to do to construct the presenter is:

presenter = new 
ViewEmployeesPresenter(this);

To do this I will take advantage of constructor chaining to offer a simple constructor that the view can consume. This “convenience” constructor will call into the “greedy” constructor (the one that requires all of the dependencies) providing it with whatever it needs:

public ViewEmployeesPresenter(
IEmployeeView view):this(view,
new EmployeeTask())
{    
}

public ViewEmployeesPresenter(
IEmployeeView view, 
IEmployeeTask task)

This frees the view from needing to know anything about any dependencies (other than itself) that the presenter requires. This is a simple solution, and it introduces coupling between the presenter and a particular implementation of one of its dependencies. However, the coupling is not terrible as it only occurs in the convenience constructor. Everywhere else in the presenter it interacts with its dependency by means of the interface. The coupling exists because now the presenter is responsible for creating its dependency (an IEmployeeTask implementation). Of course, being pragmatic, if you were trying to introduce the concepts of dependency injection and dependency inversion into your own applications, this would allow you a good starting point-with an acceptable level of coupling.

However, if you want to ensure that classes with dependencies are in no way coupled to implementations of those dependencies, you can utilize the features of a service locator.

Dependency Injection with Service Locators

To completely eliminate the need for the presenter to be aware of which implementation of IEmployeeTask it should use, you must add a new element into the mix. In the realm of dependency injection, a service locator is simply an object that knows how to retrieve dependencies for other objects. In this scenario, it would be the role of the service locator to find an implementation of IEmployeeTask that the presenter can work with. All of you who have been reading along probably know the answer to the question, “Does this mean that my presenter will now have a dependency on this service locator?” Absolutely. Then you might ask, “Does this mean I should start changing the constructor of my presenter to also allow it to accept a service locator?” You could do that. Unfortunately, if other classes down the road want to utilize the services of the locator to resolve their dependencies, they too would require a constructor that allowed them to accept an interface to the service locator. This seems like a little too intrusive to the architecture and more work than is necessary.

The solution I am going to propose is one that you can use immediately if you want to start utilizing service locators in your own projects. It is also a solution that can scale when you start using full-blown dependency injection frameworks like Windsor Castle, a popular, open-source dependency injection framework. I am first going to create an interface for the service locator:

public interface IDependencyResolver :
IDisposable
{
    void RegisterImplmentationOf<T>(
    T component);
    T GetImplementationOf<T>();
}

I am using generic methods so that I will not need to cast when invoking the locator from client methods. I stated that I want existing classes to be able to consume the functionality provided by the service locator without a need to have an explicit parameter dependency on it. To accomplish this I will use a static class that will delegate all of its calls to any particular implementation of the service locator interface:

public static  class 
DependencyResolver
{
    private static IDependencyResolver 
    resolver;

    public static void 
    RegisterResolver(
    IDependencyResolver 
    resolver)
    {
        DependencyResolver.resolver = 
        resolver;    
    }

    public static T 
    GetImplementationOf<T>()
    {
        return 
        resolver.
        GetImplementationOf<T>();
    }
        
}

Notice that the DependencyResolver class has a method called RegisterResolver which is passed an implementation of IDependencyResolver that it can forward its calls onto. What does this translate to from the perspective of the presenter? Instead of it needing to have knowledge of the EmployeeTask implementation of IEmployeeTask, it can now use the DependencyResolver class to locate an implementation of IEmployeeTask. This changes the constructors in EmployeePresenter from this:

    Public ViewEmployeesPresenter(
    IEmployeeView view):this(
    view,new EmployeeTask())
    {            
    }

    public ViewEmployeesPresenter(
    IEmployeeView view, 
    IEmployeeTask task)

To this:

public ViewEmployeesPresenter(
IEmployeeView view):this(view,
DependencyResolver.GetImplementationOf
<IEmployeeTask>())
        {            
        }

public ViewEmployeesPresenter(
IEmployeeView view, 
IEmployeeTask task)

Notice that I am still making use of the greedy constructor that requires everything that the presenter requires. I can use this constructor from a testing perspective to verify the behavior of the presenter. In the constructor that the Web page uses, the presenter uses the DependencyResolver and asks it to retrieve an implementation of an IEmployeeTask. There is nowhere in the presenter that it is coupled to the EmployeeTask component anymore!

I chose to couple the presenter to the service locator by using the static DependencyResolver class. Someone out there right now is screaming, “static classes are evil!” In addition, lots of people scream, “singletons are evil.” In either case, they are not evil, as long as they allow for testability, which is typically not easy to do with traditional singleton or static class implementations. This scenario makes testability easy because the DependencyResolver static class does nothing more than delegate its work to an IDependencyResolver implementation (which you can easily fake at test time).

The advantage of using the interface (IDependencyResolver) is that when I am first starting down the service locator route, I may be content with creating my own service locator that gets configured at application startup. Listing 8 shows the code for such a locator. Look at this code example that configures such a locator in a class that gets invoked at application startup:

public class ApplicationStartupTask
  {        
    public static void Initialize()
    {
    IDependencyResolver resolver = new
    CustomDependencyResolver();
    resolver.RegisterImplmentationOf<
    IEmployeeTask>(new 
    EmployeeTask());
      DependencyResolver.
      RegisterResolver(resolver);
        }
    }

Notice that I explicitly tell the service locator when asked for implementations of IEmployeeTask to return the EmployeeTask object. In this particular implementation it also enforces that, even though it is not explicitly marked as a singleton, the EmployeeTask will be a singleton in this application. In the final step I register the service locator with the DependencyResolver so that all clients can access its functionality.

If you want more functionality out of your service locator you may not want to code it yourself. By using the IDependencyResolver interface, you can easily switch to an implementation that leverages already existing dependency injection frameworks. Listing 9 shows an example of an IDependencyResolver implementation coded to work with Windsor Castle.

The value of coding to interfaces means that when (and if) I switch to Windsor (or another dependency injection framework), very little of my client code should change. In fact, the only change required to use Windsor is to change the ApplicatonStartupTask as follows:

public class ApplicationStartupTask
   {
      private static readonly string 
      ContainerConfigurationPath = 
      Path.Combine(AppDomain.
      CurrentDomain.BaseDirectory, 
      "container.boo");

        public static void 
        Initialize()
        {
          IWindsorContainer 
          container = new 
          WindsorContainer();
          BooReader.Read(container,
          ContainerConfigurationPath);
          DependencyResolver.
          RegisterResolver(new
          WindsorDependencyContainer(
          container));
        }
    }

The advantage of using a full-featured framework like Windsor is that there is no longer any code (not even in ApplicationStartUp) tied to particular implementations of dependencies. Objects that need dependencies can still ask the DependencyResolver class to retrieve them and the DependencyResolver will use whatever implementation of IDependencyResolver was provided to it to satisfy the request.

In the source code accompanying this article, you can see how I configure the Windsor container using Binsor, a great tool for configuring Windsor without XML files. Ayende Rahien developed Binsor and it allows me to configure dependencies using configurations stored outside of the application.

Wrapping Up

I have covered a lot of ground in this article. I started with a single-tiered application that breaks many of the best practices that many of you are already well aware of. I introduced a layered architecture and some refactorings that drove me towards utilizing the dependency inversion principle. You could see the benefit of coding to abstractions vs. implementations. To top it off, I introduced the concepts of dependency injection and service locators as tools to help you realize the benefit of coding to abstractions.

You now have knowledge of another arsenal of tips and techniques which you can start applying to realize more loosely coupled solutions in your application architectures.

public partial class ViewEmployeesTightlyCoupled : Page
{
   private const string ConnectionString = "data 
   source=(local);Integrated Security=SSPI;Initital
   Catalog=NorthWind";
   private SqlConnection connection;

   protected void Page_Load(object sender, EventArgs e)
    {
        if (! IsPostBack)
        {
         PopulateGridFrom(MapFrom(GetAllEmployees()));
        }
    }

    private DataTable GetAllEmployees()
    {
      using (connection = new 
      SqlConnection(ConnectionString))
        {
            SqlCommand command = 
            connection.CreateCommand();
            command.CommandText = "SELECT * FROM 
            Employees";
            command.CommandType = CommandType.Text;

            connection.Open();


            using (SqlDataReader reader = 
            command.ExecuteReader(
            CommandBehavior.CloseConnection))
            {
                DataTable results = new DataTable();
                results.Load(reader);
                return results;
            }
        }
    }

    private List<Employee> MapFrom(DataTable 
    employeeData)
    {
        List<Employee> employees = new 
        List<Employee>();
        foreach (DataRow employeeRow in 
        employeeData.Rows)
        {
            employees.Add(MapFrom(employeeRow));
        }
        return employees;
    }

    private void PopulateGridFrom(List<Employee> 
    employees)
    {
        this.employeesRepeater.DataSource = employees;
        this.employeesRepeater.DataBind();
    }

    private Employee MapFrom(DataRow row)
    {
        return
            new Employee(Convert.ToInt32(
            row["EmployeeId"]), 
            row["LastName"].ToString(), 
            row["FirstName"].ToString(), 
            row["Title"].ToString(),
            Convert.ToDateTime(row["BirthDate"]), 
            Convert.ToDateTime(row["HireDate"]));
    }
}

public partial class 
ViewEmployeesWithAdditionOfPresenter : Page, 
IEmployeeView
{
    private ViewEmployeesPresenterLowCohesion 
    presenter;

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        presenter = new 
        ViewEmployeesPresenterLowCohesion(this);
    }

    public IList<IEmployee> Employees
    {
        set
        {
            this.employeesRepeater.DataSource = value;
            this.employeesRepeater.DataBind();
        }
    }

}

public class ViewEmployeesPresenterLowCohesion
{
    private IEmployeeView view;
    private const string ConnectionString = "data
    source=(local);Integrated Security=SSPI;
    Initital Catalog=NorthWind";
    private SqlConnection connection;


    public ViewEmployeesPresenterLowCohesion(
    IEmployeeView view)
    {
        this.view = view;
        HookupEventHandlersTo(view);
    }

    private void HookupEventHandlersTo(
    IEmployeeView view)
    {
       view.Load += delegate { LoadEmployees(); };
    }

    private void LoadEmployees()
    {
       if (view.IsPostBack) return;
        view.Employees = MapFrom(GetEmployees());
    }

    public DataTable GetEmployees()
    {
       using (connection = new 
       SqlConnection(ConnectionString))
        {
           SqlCommand command = 
           connection.CreateCommand();
           command.CommandText = "SELECT * FROM 
           Employees";
           command.CommandType = CommandType.Text;
           connection.Open();

           using (SqlDataReader reader = 
           command.ExecuteReader(
           CommandBehavior.CloseConnection))
           {
              DataTable results = new DataTable();
              results.Load(reader);
              return results;
           }
       }
   }

   private IList<IEmployee> 
   MapFrom(DataTable employeeData)
   {
       List<IEmployee> employees = new 
       List<IEmployee>();
       foreach (DataRow employeeRow in 
       employeeData.Rows)
       {
           employees.Add(MapFrom(employeeRow));
       }
       return employees;
   }

   private Employee MapFrom(DataRow row)
  {
       return
           new Employee(Convert.
           ToInt32(row["EmployeeId"]), 
           row["LastName"].ToString(),
           row["FirstName"].ToString(), 
           row["Title"].ToString(),
           Convert.ToDateTime(row["BirthDate"]),
           Convert.ToDateTime(row["HireDate"]));
   }
}

public class ViewEmployeesPresenter
    {
        private IEmployeeView view;
        private IEmployeeTask task;

        public ViewEmployeesPresenter(IEmployeeView
        view, IEmployeeTask task)
        {
            this.view = view;
            this.task = task;

            HookupEventHandlersTo(view);
        }

        private void
        HookupEventHandlersTo(IEmployeeView view)
        {
          view.Load += delegate { LoadEmployees(); };
        }

        private void LoadEmployees()
        {
            if (view.IsPostBack) return;

            view.Employees = task.GetAllEmployees();
        }
    }

public DataTable GetEmployees()
{
    using (connection = new 
    SqlConnection(ConnectionString))
    {
        SqlCommand command = 
        connection.CreateCommand();
        command.CommandText = "SELECT * FROM 
        Employees";
        command.CommandType = CommandType.Text;

        connection.Open();

        using (SqlDataReader reader = 
        command.ExecuteReader(
        CommandBehavior.CloseConnection))
        {
            DataTable results = new 
            DataTable();
            results.Load(reader);
            return results;
        }
    }
}

private IList<IEmployee> MapFrom(DataTable 
employeeData)
{
    List<IEmployee> employees = new 
    List<IEmployee>();
    foreach (DataRow employeeRow in 
    employeeData.Rows)
    {
    employees.Add(MapFrom(employeeRow));
    }
    return employees;
}

private Employee MapFrom(DataRow row)
{
    return
    new Employee(Convert.ToInt32(
        row["EmployeeId"]), 
        row["LastName"].ToString(), 
        row["FirstName"].ToString(), 
        row["Title"].ToString(),
        Convert.ToDateTime(row["BirthDate"]),
        Convert.ToDateTime(row["HireDate"]));
}

public class 
EmployeeTaskLowCohesionNoDependencyInversion :
IEmployeeTask
    {
        public const string ConnectionString = "data 
        source=(local);Integrated Security=SSPI;
        Initial Catalog=Northwind";
        private SqlConnection connection;
        
        public IList<IEmployee> GetAllEmployees()
        {
            return MapFrom(GetEmployees());
        }

        public DataTable GetEmployees()
        {
            using (connection = new
            SqlConnection(ConnectionString))
            {
               SqlCommand command = 
               connection.CreateCommand();
               command.CommandText = "SELECT * FROM 
               Employees";
               command.CommandType = CommandType.Text;

               connection.Open();

                using (SqlDataReader reader = 
                command.ExecuteReader(
                CommandBehavior.CloseConnection))
                {
                    DataTable results = new 
                    DataTable();
                    results.Load(reader);
                    return results;
                }
            }
        }

        private IList<IEmployee> 
        MapFrom(DataTable employeeData)
        {
            List<IEmployee> employees = new 
            List<IEmployee>();
            foreach (DataRow employeeRow in 
            employeeData.Rows)
            {
                employees.Add(MapFrom(employeeRow));
            }
            return employees;
        }

        private Employee MapFrom(DataRow row)
        {
            return
                new Employee(Convert.ToInt32(
                row["EmployeeId"]), 
                row["LastName"].ToString(), 
                row["FirstName"].ToString(),
                row["Title"].ToString(),
                Convert.ToDateTime(row["BirthDate"]), 
                Convert.ToDateTime(row["HireDate"]));
        }
    }

public DataTable GetEmployees()
{
    using (IDbConnection connection  = 
    connectionFactory.Create())
    using (IDbCommand command = 
    connection.CreateCommand())
    {
       command.CommandText = "SELECT * FROM 
       Employees";
       command.CommandType = CommandType.Text;
       connection.Open();
       using (IDataReader reader = 
       command.ExecuteReader(
       CommandBehavior.CloseConnection))
        {
            DataTable results = new 
            DataTable();
            results.Load(reader);
            return results;
        }
    }
}

public class CustomDependencyResolver : 
IDependencyResolver
    {
        private IDictionary<Type, object> components;

        public CustomDependencyResolver()
        {
           components = new Dictionary<Type, 
           object>();
        }

        public void RegisterImplmentationOf<T>(T 
        component)
        {
            components.Add(typeof (T), component);
        }

        public T GetImplementationOf<T>()
        {
            return (T) components[typeof (T)];
        }

        public void Dispose()
        {
            components.Clear();  
        }
    }

public class WindsorDependencyContainer : 
IDependencyResolver
    {
        private IWindsorContainer underlyingContainer;

        public WindsorDependencyContainer(
        IWindsorContainer underlyingContainer)
        {
            this.underlyingContainer = 
            underlyingContainer;
        }

        public void RegisterImplmentationOf<T>(T 
        component)
        {
            throw new NotImplementedException();
        }

        public T GetImplementationOf<T>()
        {
            return underlyingContainer.Resolve<T>();
        }

        public void Dispose()
        {
            underlyingContainer.Dispose();
        }
    }