Decorator Design Pattern in ASP.NET Core

The decorator pattern (also known as Wrapper) is a structural design pattern and it allows developers to dynamically add new behaviors and features to existing classes without modifying them thus respecting the open-closed principle. This pattern lets you structure your business logic into layers (wrappers) in a way that each layer adds some additional behavior or functionality to an existing object, promoting separation of concern. Furthermore, these layers can be added or removed at runtime and clients can also use the different combinations of decorators to be attached to an existing object.



Pros Decorator Pattern

  1. We can extend an object’s behavior without creating a hierarchy of new child classes.

  2. We can add or remove features from an object at runtime which gives developer flexibility not available in simple inheritance.

  3. We can combine several features by wrapping an object into multiple decorators

  4. We can divide a complex object into several smaller classes with specific behaviors which promotes the Single Responsibility Principle

  5. It supports the Open-closed principle which states that the classes should be open for extension but closed for modification.


Cons Decorator Pattern

  1. The object instantiation can be complex as we have to create an object by wrapping it in several decorators.

  2. Sometimes, it’s hard to keep track of the full wrapper stack, and removing a specific wrapper from the stack is not something easy to achieve.

  3. Decorators can cause issues if the client using them relies heavily on the object concrete type.


Getting Started with Decorator Pattern in ASP.NET Core 5

The decorator pattern can be used to attach cross-cutting concerns such as logging or caching to existing classes without changing their code. Let’s create a new ASP.NET Core 5 REST API to learn how to use the decorator pattern to dynamically add/remove logging and caching features.


First of all, create the following Player model class in the Models folder of the project.


Next, create the following PlayerService and return a fake list of players. Of course, in a live application, this type of service will fetch data from a backend databa