concept Decorators in category dependency injection

This is an excerpt from Manning's book Dependency Injection. Login to get full access to this book.

This is a standard application of the Decorator design pattern that we mentioned in section 1.1.2. We’ll talk much more about Decorators in chapter 9.

Listing 15.7 Decorating generic Auto-Registered Abstractions

Assembly assembly = typeof(AdjustInventoryService).Assembly;

var mappings =
    from type in assembly.GetTypes()    #1  
    where !type.IsAbstract    #1  
    where !type.IsGenericType    #1  
    from i in type.GetInterfaces()    #1  
    where i.IsGenericType    #1  
    where i.GetGenericTypeDefinition()    #1  
        == typeof(ICommandService<>)    #1  
    select new { service = i, implementation = type };  #1  

foreach (var mapping in mappings)
{
    Type commandType =    #2  
        mapping.service.GetGenericArguments()[0];    #2  

    Type secureDecoratoryType =    #3  
        typeof(SecureCommandServiceDecorator<>)    #3  
            .MakeGenericType(commandType);    #3  
    Type transactionDecoratorType =    #3  
        typeof(TransactionCommandServiceDecorator<>)    #3  
            .MakeGenericType(commandType);    #3  
    Type auditingDecoratorType =    #3  
        typeof(AuditingCommandServiceDecorator<>)    #3  
            .MakeGenericType(commandType);    #3  

    services.AddTransient(mapping.service, c =>    #4  
        ActivatorUtilities.CreateInstance(    #4  
            c,    #4  
            secureDecoratoryType,    #4  
            ActivatorUtilities.CreateInstance(    #4  
                c,    #4  
                transactionDecoratorType,    #4  
                ActivatorUtilities.CreateInstance(    #4  
                    c,    #4  
                    auditingDecoratorType,    #4  
                    ActivatorUtilities.CreateInstance(  #4  
                        c,    #4  
                        mapping.implementation)))));    #4  
}

#1   Scans the given assembly for non-generic ICommandService<TCommand> implementations
#2   Extracts the concrete TCommand type from the closed ICommandService<TCommand> Abstraction
#3   Uses the extracted commandType to build closed generic implementations of the Decorators that need to be applied
#4   Adds a delegate registration for the closed ICommandService<TCommand> Abstraction. This delegate calls ActivatorUtilities’s CreateInstance method multiple times to Auto-Wire all Decorators and the scanned implementation as innermost component.

copy

Although consumers that rely on sequences of Dependencies can be the most intuitive use of multiple instances of the same Abstraction, Decorators are another good example. But there’s a third and perhaps a bit surprising case where multiple instances come into play, which is the Composite design pattern.

This is an excerpt from Manning's book Dependency Injection in .NET. Login to get full access to this book.

The SecureMessageWriter class implements the IMessageWriter interface while also consuming it: it uses CONSTRUCTOR INJECTION to request an instance of IMessageWriter. This is a standard application of the Decorator design pattern that I mentioned in section 1.1.2. We’ll talk much more about Decorators in chapter 9.

In chapter 8, you saw several examples of how to compose a ProductManagementService instance. Listings 8.4 and 8.5 provided the most correct implementation, but, in the following listing, we’ll ignore that SqlProductRepository is disposable in order to focus on composing Decorators.

Because you’ve already seen the InsertProduct method in listing 9.4, the purpose of this code example is to illustrate the repetitive nature of Decorators used as aspects. The only difference between the DeleteProduct and InsertProduct methods is that they each invoke their own corresponding method on the decorated agent.

¹⁵ Read more about Decorators and T4 templates at Oleg Sych, How to use T4 to generate Decorator classes, 2007, www.olegsych.com/2007/12/how-to-use-t4-to-generate-decorator-classes/

Figure 9.10. T4 makes it possible to auto-generate Decorator code from templates. The starting point is a template prototype that understands the basic concept of Decorator. The template prototype contains the code generation code that will generate the frame of the decorating class, but it doesn’t define any aspect code. From the template prototype, an aspect template that describes how a specific aspect (such as Circuit Breaker) should be applied when decorating any interface is developed. The result of that is a specialized template (SomeAspect.tt) for that particular aspect, which can be used to generate Decorators for particular interfaces. The result is a normal code file (SomeAspectDecorator.cs) that compiles normally together with other code files.