The N-layer myth and basic Dependency Injection

Dividing an application in N layers is considered a standard and a best practice. It is often thought that this automatically creates a decoupled application. However, just creating layers doesn’t make your code loosely coupled.

A typical N-layer application

Let’s take a simple layered application:

1. A typical N-layer architecture

In the above image you can see how the application is structured. The responsibilities for every layer are:

UI layer: This can be a WPF-app, a console-app, a web application, etc. It defines the user interface and no logic should be in this layer.

Domain Layer: It coordinates the interactions between UI, Model and DAL. It includes classes such as TaskService.

DAL: Responsible for saving and retrieving stored instances. A typical class would be a TaskRepository.

Model: A layer that spans all three layers. This usually consists of POCO-objects. The Task-class is an example.

One might think that separating the application into these layers guarantees loose coupling. In a few moments I’ll show you why that’s not necessarily true. First, let’s look at how these layers are usually tied together, from the bottom up:

Model

This layer holds the basic entities. This is the Task-entity, a simple POCO-class:

DAL

In the Data Access Layer typically there’s a repository class which allows access to the underlying data store. In this example, I will be using Entity Framework. The actual technology is not important, you could swap it out with whatever data storage technique you’re using. I chose Entity Framework because it makes the code samples very concise. The repository has two methods: one to retrieve a Task by ID and another one which accepts an arbitrary where-clause.

UI Layer

For the UI layer I chose an ASP.NET MVC application. I chose this because it makes the example represent a real-world scenario more closely. I will not enter into detail on how MVC works, I will only show you the controller part. If you don’t know MVC, for now you can just assume that the controller handles an HTTP-request. Let’s see what the controller does in order to visualize the tasks that are due today:

Result

The above structure is very typical and by some considered a best practice. However, there are a few problems. Let’s take a look at figure 1 again and examine the dependency graph. You can see that all the dependencies point downward. Now, let’s see whether the current dependency graph is desirable.

One of the principles of loose coupling is that you need to be able to use each component in isolation. Is this possible for all our components?Certainly, you would need to develop alternatives for their dependencies, but this should be doable without modifying the existing component. So let’s take a look at each component:

User Interface: With the current dependency graph, it certainly is possible to swap out the UI for another one. We just create a new project (WPF, Console, …), add references to Domain and Model and we are good to go. We didn’t need to modify existing code. So far, the dependency graph is OK.

Domain and Model: Swapping out these layers doesn’t really make sense. Since it’s the core of the project, swapping it out would basically mean creating a new project.

DAL: Replacing a DAL is typically why people advocate loose coupling. (“What if need to switch Database providers?”) Although this usually doesn’t happen, it still is a good practice to decouple the Domain from the DAL. If we remove the DAL from the solution, we will run into a problem. The problem is that our Domain-layer has a hard reference to our TaskRepository. If we want to swap out the DAL, we’ll have to modify the Domain-layer.

N-layer application with basic Dependency Injection

Ideally, what we want is that the domain-layer and the model-layer have no hard dependencies. They should be able to use external facilities, but they should have no knowledge of how those facilities handle requests, they should only know what they do.

This is a basic example of a more desirable dependency graph:

2. Inverted dependency graph

As you can see, there’s a slight but important difference: the dependency between the Domain and the DAL has been inverted. Looking at this graph, you can see that now you could swap out the DAL without touching the domain layer.

Now how can we achieve this graph?

Implementing the graph

Implementing the graph is quite easy:

Remove the reference from Domain to DAL

Create a reference from DAL to domain

This will cause compiler errors of course. The TaskService has a reference to TaskRepository but since the domain has no reference to the DAL, we receive a compiler error. We need to invert the dependency.

Inverting the dependency

To invert the dependency we will execute the following steps:

Create an interface which describes the public interface of a repository

Let the TaskRepository implement this interface

Make sure TaskService references only the Interface

Pass an object that implements the IRepository interface to the TaskService

Since we still need to be able to access the repository, we need to define an Interface in the Domain-layer which defines what a Repository can do:

Now we are passing an object into the constructor, which must implement the ITaskRepository interface. This is known as Constructor Injection. This is necessary because we don’t want a reference to any specific repository.

This of course affects the UI layer, because now the TaskService does not have a default constructor anymore. To overcome this problem, let’s apply the same steps:

Now, the TaskRepository, the TaskService and the TaskController are completely decoupled from each other and only depend on interfaces.

Looking at the current state of the code, you might ask what the real benefit is. After all, there’s still a dependency on the TaskRepository when we want to construct the TaskController, we just moved it to the top of the application.

The benefit is exactly this, instead of having implicit dependencies in the entire application we can now push all the dependencies into one single place and manage them all from a centralized location. This location is usually referred to as the Composition Root. Thinking in terms of the Single Responsibility Principle (every class should have a single responsibility), you could say that we moved the responsibility for managing their dependencies from the TaskController and the TaskService to another, dedicated class.

Apart from that, we’re also enabling unit tests, we can now create fakes and pass them to the TaskController or the TaskService and test them in isolation.

Implementing the composition root

With everything decoupled, we do need a way of coupling these items at runtime. At runtime, an interface doesn’t do anything for you, so we need concrete implementations.

First I will show a simple (hard coded) implementation.

In this case, since we’re using ASP.NET MVC as the UI application, the construction of the controller will be handled by the framework itself. Using the default configuration, MVC will look for a controller with the name specified in the URL like this:

/{controller/{action}

This means that accessing the URL /Task/DueTasks will execute the method we specified. By default, it will try to use the default constructor. In our case, there isn’t any default available and this will fail. To solve this, we need to plug into the framework by creating a new ControllerFactory:

The framework already helps us by parsing the URL and passing the necessary information. Then, instead of letting it handle the construction, we plug in our own implementation. MVC gives us the name of the controller it wants and then lets us decide how we want to construct it. The given implementation is a very crude one and should not be used in a real-world scenario. I’m showing it here so you can see that the dependencies are resolved in a single place. This is the Composition Root.

For completeness sake,I’m also showing you how to plug this class into the MVC framework. You need to register it inside the Application_Start event in the global.asax-file:

As mentioned before, the benefit is that we are moving the burden of managing dependencies from the classes inside the application towards a centralized class. Replacing the DAL now only requires us to create a new DAL and modify the Composition Root. In this small example, the benefits may not be that obvious, but that’s because we only have a few classes. If you extrapolate this to a complete application, the benefits get a lot more obvious.

Using a DI container

The implementation that I showed in the previous section is admittedly not a very good one. It means that for every controller and dependency you add, you’d have to modify the MyControllerFact, which is not a very maintainable solution. Therefore, I will show you an implementation with a DI Container. A DI Container is a reusable component that provides dependency functionality. There are two steps to using a container:

Configuring the container

Using the container to resolve dependencies

In the next example I’m going to use the Ninject DI Container. If you want to use a different container you will need to look up the specific API.

Configuring the container

In the configuration step, you basically tell the container what object to construct when asked for a specific interface:

Other features of DI Containers

Apart from resolving dependencies, a DI Container offers a lot more features. Which features are supported depends on the container you choose:

Lifetime management: when configuring the container, you can specify whether to create a new instance or to return the same instance every time. Different containers can have more possibilities (such as one per request or custom lifetimes)

Configuration: In this example I showed how to configure the container with the Fluent API. This requires you to recompile the application if you want change the configuration. Some DI containers offer XML configuration or even a combination of both. That way you don’t need to recompile if you want to swap out certain modules.

Auto-registration: Closely related to configuration is auto-registration. In the previous example we had to explicitly tell the container which concrete implementation goes with which interface. Auto-registration allows you to do this mapping with convention over configuration. If there’s no concrete class bound, then check if we can find a class that follows a set of conventions.

Interception: Since the DI container knows the interfaces, it could possibly wrap the interfaces and intercept all the calls. This can be useful for solving cross-cutting concerns such as logging and security. The concept is the same as an AOP (Aspect Oriented Programming) framework such as PostSharp. The difference is that with a DI container this is a dynamic feature, whereas PostSharp uses post-compilation steps. Interception with DI containers is much more flexible, because it allows you to modify cross cutting concerns at runtime or even through configuration.

Conclusion

Even when using distinct layers it’s very easy to fall into the trap of writing tightly coupled code. Furthermore, the latest IDE’s (such as Visual Studio) are really excellent. This also means that they enable you to create dependencies very easily. In order to avoid this, you should always consider that you’re creating a hard reference when performing either one of the following two actions:

Using the new-keyword to create an instance

Adding a reference to another library

As a mental rule, I always force myself to think whether it’s really necessary and if there’s an alternative when I want to do either of these actions.

Note: the ideas expressed in this post are loosely based on the introduction from the book “Dependency Injection in .NET” by Mark Seemann. If you want to learn more about Dependency Injection, I would recommend you read this book. It is an amazing source of information, well written and it covers the ins and outs of Dependency Injection as well as several DI Containers.

Very nice article, I got the key points to introduce these concepts to newbie, thank you.

throwexception

For this to work, don’t you have to add a reference to the DAL in the UI layer? How else can you bind the concrete type TaskRepository to the ITaskRepository?

http://www.kenneth-truyers.net/ Kennethtruyers

Yes, correct. But that’s OK, it’s not like your views are depending on your data-access, it’s your application that’s depending on your DAL, which is fine, because it does actually depend on it. If it is depending on your DAL through your domain it’s just less explicit.

Michael S

When I first saw this architecture in practice, I looked for an article like this. I have used this architecture for a few years, and really like it. One company I was with needed to create mobile site, and with this in place it was a matter of just adding another project that could leverage that services class layer. I proposed this for a new site and was dinged because the DI takes place in the MVC app which means you have to reference the DAL. I like your answer. I am curious if you have used this under different physical deployment scenarios. I have 2 deployment scenarios I am looking at. One is entirely behind a firewall so no issue there. Second scenario is where the ui may have to reside in a DMZ. My prototype now has a RESTful API to wrap the provider layer. I can deploy the same app inside/outside the DMZ. The app running in the DMZ can be configured to hit the RESTful service. Thoughts?

http://www.kenneth-truyers.net/ Kennethtruyers

If your MVC app talks to an abstraction of your service class, it shouldn’t be a problem.

Say you have an IService-class which your MVC app uses.

When you deploy your app onto two physical tiers, you can create a ServiceProxy that implements that interface, but instead of calling the actual code, it calls the REST-service. In your composition root, you’d then wire your MVC controller to the proxy.

When you deploy your app on a single tier, you wire the MVC controllers directly to the service class (which implements the same interface). Obviously under different physical deployment scenarios you need to alter your wiring, but that’s exactly what DI is very good for.

As for the DI taking place inside the MVC app, in your case you’d have to move that outside of your MVC app, because you obviously do not want a direct dependency on your DAL or Domain layer.

Tommy Long

When working with multiple application entry points (like in the case of seperate Web and Mobile projects) refactor your DI to a composition root project which is immediately invoked by your application entry points. Any differences in dependencies between your entries can be managed at this stage.

Mac

I don’t see how and why would you need to reference DAL in the UI layer? In the UI layer, we would only need the TaskService, and for that we have the ITaskService which we have defined in the BLL (or the Domain layer as you have called it here), so where do we need the DAL reference in the UI?

Mac

I don’t see how and why would you need to reference DAL in the UI layer? In the UI layer, we would only need the TaskService, and for that we have the ITaskService which we have defined in the BLL (or the Domain layer as you have called it here), so where do we need the DAL reference in the UI?

http://www.kenneth-truyers.net/ Kennethtruyers

You need it in your composition root, the place where you wire everything together. Usually that is defined in the UI-layer.

Mac

Yes, thanks for explaining. But is it possible thay we have a composition root in the UI and in the BLL as well. So in the UI we bind the DomainLayer interface to it’s class (ITaskService to TaskService) and have a separate composition root in DomainLayer (like using Ninject in there too) and binding DAL interface to concrete classes there? I know this isn’t probably a usual practice, but can we do that, and more importantly should we do it? Or is there something against it?

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

Gerry

Exactly this is what I asked myself last week, making some architectural choices for a new project. This would have been my wish as well! Giving each layer its own DI composition root. I understand that (logical) separation can be achieved using namespacing, but this approach just seems more intuitive and prevents accidental ‘breaching’ a layer by a unaware developer. Could you please share your final thoughts on this? I would greatly appreciate it.

David Troyer

Is it okay for the POCO class (Task) to be coupled across all layers?

http://www.kenneth-truyers.net/ Kennethtruyers

When you have all your references pointing down, there’s really no other solution than that. However, when your references all point to your domain, your Task-class can be part of your domain and then your data and UI layer all just depend on that, which is fine.

In a CRUD type of application, this probably fine. If you move away from CRUD (typically more complex applications) and move to a more DDD, CQRS-style of application, you probably move away from POCO-classes and put behavior on those classes. In that case it might be a good idea to make them internal.

David Troyer

If I put the Task POCO in the Domain layer, the inverted dependency graph picture would no longer show the relationship of the UI and DAL to the Model? As far as DDD and CQRS, I am reading your Introduction to DDD, CQRS, and Event Sourcing blog. Thx!

Tommy Long

No!

Your DAL should return Domain Entities, which it creates using it’s private Data Access Entities (think converting Entity Framework mapped classes to POCOs). Place Domain Entities in a tertiary DLL that both your DAL and Domain can reference.

Your UI should work with View Models in the views (consider MVC as View Model – View – Controller). Your controller can translate your view models to domain entities to interact with your domain (consider the example of a WPF viewmodel, often heavily burden with Viewstate properties and additional components for binding, given the example on this page your DAL would be interacting directly with these monoliths??).

svenn

Very good article!
Thankyou

svenn

Very good article!
Thankyou

Tommy Long

Credit for writing this all up, but I honestly believe it’s the kind of introduction of malpractice I would expect from someone with insufficient experience. You will look at this article in a couple of years and be shocked at how many issues your proposed architecture introduces.

I’d be interested to see whether you would come up with the same end-product if you break down the problem, perhaps each layer’s interaction with it’s neighbour, in smaller articles.

I suggest researching the subject some more. Don’t be put off by my criticism, instead I hope you endeavour to learn what the issues are.

Pawel

Yeah I think the same. This kind of architecture can handle cleanly maybe 20 views and trivial domain logic and is nightmare when you have to optimize performance

http://www.kenneth-truyers.net/ Kennethtruyers

Could you indicate what issues you think this architecture introduces (and what do you think is a better approach)? There are other approaches as well as I detailed in a few other articles, but I am mainly focusing on common issues I see in the always returning “N-tier”-architectures like it’s a gold standard. It does have its benefits but it seems to get applied the wrong way in 90% of the cases I have seen.

Armando Pitotti

Your exposure are very interesting and push me to expose another issue, for a bit time follow me in my reasoning.

In a typical application with N-layer architecture, You have :

1° UI layer.
2° Service layer, it’s necessary if you want expose, in the future, your business, in a nutshell SOA architecture.

3° Business layer.
4° Dal layer.
5° Common Layer, which is common all others layer.

The UI expose to client with ModelView.
The UI comunicate with Service throught DTO objects, POCO classes.
The Service comunicate with Businees throught DTO objects.
The Business comunicate with Dal throught Domain model, POCO classes.

ModelView, DTO and Model domain are in the Common layer.
(***)In Common layer you have classes for map the objects to each other, Mapper classes.

This tipical solution architecture are exposed in a good book, Microsoft dotNET – Architecting Applications for the Enterprise, from Dino Esposito and Andrea Saltarello.

With classic schema and DI we can increase the isolation between layers,
your consideration for inverting dependency between Domain and Dal it’s very interesting.

If we use the IoC(Unity), it’s easier add and remove dependency.
It’s all ok!, Noooo!!!

I have moved the problem, which you have correctly exposed, to the mapper classes.

I worked on 3 medium/large web projects, and I have the same problem, always!
We spend much time to creating mapper classes, and much of business logic is filed in mapper classes.

The loose coupling throught the DI is essential for maintenance for the team which has created the project, will be able to intervene much more easly.

But DI not resolve the reuse of layer for others project, for that there must be a strategy from the IT sector of the company.
An example of possible strategy could be the DDD.
The Domain model includes the whole issue of company, it’s ready for use in all projects of company, so doing the Dal layer could be reused.

I’d like to hear an opinion for the problem at the Mappers objects.

http://www.kenneth-truyers.net/ Kennethtruyers

Indeed the mapping problem sounds very familiar.

I found the best solution for this is to separate your read and write models. That way you can have a read-model that is essentially read directly from the DB (no domain logic there, just get directly what you need from the DB). On the other side you have a write model which can include all the domain logic.

Here’s an article I have written about this which explains in more detail what I mean:

Amazing post. After weeks and weeks of searching I finally found this post which broke everything down for me. I have a few small questions since I am relatively new to this. I’m aware that the ITaskRepository is placed in the Domain layer and the TaskRepository that is in the DAL uses it. Although, I am unaware of which layer we put the ITaskService interface being that the TaskService is located in the Domain layer. I was assuming it would go in the Domain layer but then started thinking maybe it goes in the UI layer. If both sets of Interfaces actually do go in the domain Domain how do you normally organize your Domain? Another question would be: Does Ninject only need to be installed to the UI layer and do bindings only need to be set in the UI layer using a NinjectDependencyResolver class. Last question is: The way it looks especially if I use database first my edmx and autogenerated stuff will be in the Model layer and then my DAL will only hold repository classes correct? Just confirming. Again, thank you so much for this post.

http://www.kenneth-truyers.net/ Kennethtruyers

I put all interfaces inside the domain layer. If you put the ITaskService in the UI-layer and you are using different projects, you get a circular reference (Domain references UI, UI references domain). There’s different ways of organizing the domain layer, either you could put all interfaces into a separate namespace (contracts or interfaces or …) or what I usually do is put the interfaces as close as possible to its implementations.

Ninject: yes you only need it in the Composition Root, which is usually located in the UI.

EF: It depends, if you want to use the generated classes directly as your domain classes, then yes, they go in the model and your DAL holds the repositories. If you want to use them as DTO’s and have richer domain classes, then you can put them in your DAL and have the repositories convert the DTO’s to the richer domain objects. For complex apps I prefer the second approach, but there other patterns available to deal with more complex applications: For that, check out my series on simplicity in software (which also has a demo app on github)

bluetea55z .

Thank you for clearing those things up. Lets say I put my EDMX in the Data layer and in my Model layer create a DTO to match each auto-generated class and eventually end up using Auto-Mapper. Which one references my Service layer and which one has the Repositories in it?

http://www.kenneth-truyers.net/ Kennethtruyers

Why would you want to create separate DTO’s, you already have DTO’s in the form of the autogenerated classes?

What you’d want to do is create domain classes. In that case, just remove the Model-project altogether and let you repositories return your domain classes. Your autogenerated classes would be internal to your data layer and in your repositories you would use automapper to convert from the autogenerated classes to the domain model