Apply the decorator pattern in .NET using Autofac
Tags: programming, technology, coding, softwaredevelopment
Published: 2018-03-20 19:50:07

---
title: Apply the decorator pattern in .NET using Autofac
published: true
tags: programming,technology,coding,software-development
canonical_url: https://hackernoon.com/apply-the-decorator-pattern-in-net-using-autofac-957502b771f7
---

![](https://cdn-images-1.medium.com/max/960/1*Cl1FLSzewuybqI18Gliv8w.png)<figcaption>Russian Dolls — metaphor to extend a given functions behavior. Photo borrowed from <a href="http://maxpixel.freegreatpicture.com/Traditional-Russian-Toy-Russian-Doll-Russian-1090697">Maxpixel</a>.</figcaption>

To follow good design principles and structure when you develop applications is something I advocate.

As the development process goes on we add new functionality to our applications: it could be a feature request from your client or it could be improvements that you’ve suggested. No matter what, these upcoming changes will also change the already given codebase. When changes are introduced we want this to be as easy as possible.

In this post I’m going to show you an example of how you can utilize the decorator pattern with the powerful IoC container [Autofac](https://autofac.org/) in scenarios where you want to extend functionality to an existing feature.

Lets say you are about to build a service that serves products. We will call this service **IProductRepository** and for simplicity we only use one method called _GetById_. It could look something like this with an implementation connected to it:

{% gist https://gist.github.com/nengberg/96e49fd83e37d89af9b6 %}

Normally you would register your concrete implementation XmlProductRepository as IProductRepository with the following code line to support the [_dependency inversion principle_](https://en.wikipedia.org/wiki/Dependency_inversion_principle):

{% gist https://gist.github.com/nengberg/a1c798000c81a3bec131 %}

Lets say that you after a while need some logging when products are fetched. How do you accomplish this?

It is tempting to just modify the implementation XmlProductRepository by injecting a logging service like this:

{% gist https://gist.github.com/nengberg/0cc8aab6ad632b7ef1ad %}

But that violates the [open/closed principle](https://en.wikipedia.org/wiki/Open/closed_principle). The principle states that you are not allowed to modify classes, but you can extend them. Here the decorator pattern is really handy.

Instead of cluttering down your original implementation you _extend_ it by adding a logging proxy, and register it as a decorator of it.

{% gist https://gist.github.com/nengberg/76d07f5d63595427647b %}

You will have to modify one code line though, and that one is the registration of the _original implementation_. It will need to be a named registration now so we can refer to it when we register our decorator:

{% gist https://gist.github.com/nengberg/52c05ac1f40d72c82357 %}

And then connect and register the decorator:

{% gist https://gist.github.com/nengberg/ed0e572e7b0b7f3a2f09 %}

The key that we use to refer to the implementation here is _productRepository_. When you have this code in place the first class that will be invoked when you inject your IProductRepository is the LoggingProductRepositoryProxy, and as we have injected the inner implementation to it it will just work as a proxy (russian doll style) following the open/closed principle.

Lets say that you experience your XmlProductRepository slow and you need to cache your products for a while. How would you implement that? It is pretty easy to just add another decorator on top of your logging implementation:

{% gist https://gist.github.com/nengberg/54a0bfcbd9e834a58354 %}

Pretty flexible!

The decorator pattern in really powerful when it comes to supporting _cross cutting concerns_ within applications.

Did you find this post useful? You know what to do! 👏

[![](https://cdn-images-1.medium.com/max/700/1*PZjwR1Nbluff5IMI6Y1T6g@2x.png)](https://goo.gl/w4Pbea)

* * *