This chapter examines two primary techniques for implementing cross-cutting concerns: runtime interception and compile-time modification. While Chapter 10 focused on design-centric AOP approaches using SOLID principles, this discussion centers on tool-assisted implementations. We'll evaluate dynamic interception as a pragmatic solution and analyze why compile-time weaving conflicts with dependency management principles.

Runtime Interception Mechanisms

Consider a scenario where multiple repository methods require identical logging behavior. Without interception, developers face repetitive code patterns:

public void Save(Order order)
{
    logger.LogStart("Save");
    try
    {
        repository.Save(order);
        logger.LogSuccess("Save");
    }
    catch (Exception ex)
    {
        logger.LogError("Save", ex);
        throw;
    }
}

public void Delete(Guid id)
{
    logger.LogStart("Delete");
    try
    {
        repository.Delete(id);
        logger.LogSuccess("Delete");
    }
    catch (Exception ex)
    {
        logger.LogError("Delete", ex);
        throw;
    }
}

This repetition violates the DRY principle. Runtime interception automates decorator creation through dynamic proxy generation. The interception library constructs proxy classes during application initialization that wrap target implementations while injecting cross-cutting behavior.

Implementing a Request Logger Interceptor

Using a hypothetical ProxyFramework, interceptors implement a core interface with a single invocation handler:

public class RequestLoggerInterceptor : IMethodInterceptor
{
    private readonly IRequestLogger _logger;
    
    public RequestLoggerInterceptor(IRequestLogger logger)
    {
        _logger = logger;
    }

    public void Intercept(MethodInvocationContext context)
    {
        string methodName = context.Method.Name;
        _logger.LogStart(methodName);
        
        try
        {
            context.Proceed();
            _logger.LogSuccess(methodName);
        }
        catch (Exception ex)
        {
            _logger.LogError(methodName, ex);
            throw;
        }
    }
}

The Intercept method receives contextual information about the target method call. The Proceed call advances execution to the wrapped component while maintaining the call stack. This generic implementation handles any method signature through runtime reflection.

Composition Root Integration

Integration occurs during application bootstrapping:

var proxyFactory = new ProxyFactory();
var logger = new ConsoleRequestLogger();
var realRepository = new SqlOrderRepository();

IOrderRepository proxiedRepository = proxyFactory.CreateProxy<IOrderRepository>(
    realRepository,
    new RequestLoggerInterceptor(logger)
);

The proxy factory generates a runtime implementation of IOrderRepository that delegates calls to the interceptor before invoking the actual repository. This approach maintains Pure DI patterns while automating decorator creation.

Runtime Interception Limitations

Despite its utility, runtime interception introduces several constraints:

• Reflection overhead: Method invocation analysis requires runtime type inspection, complicating parameter manipulation and error handling
• Tooling depandency: Interceptors become tightly coupled to the interception framework's abstractions
• Abstraction constraints: Only interface methods or virtual members can be intercepted
• Design preservation: Fails to address underlying architectural issues in the target codebase

These limitations make runtime interception suitable as a transitional solution until architectural improvements can be implemented, but not as a long-term substitute for proper design.

Compile-Time Modification Analysis

Compile-time weaving alters compiled assemblies by injecting aspect code during the build process. Consider a retry policy applied via attributes:

public class PaymentProcessor : IPaymentService
{
    [RetryPolicy(MaxAttempts = 3)]
    public void ProcessPayment(decimal amount) { ... }
}

The aspect implementation would resemble:

[AttributeUsage(AttributeTargets.Method)]
public class RetryPolicyAttribute : MethodInterceptionAspect
{
    public int MaxAttempts { get; }
    
    public RetryPolicyAttribute(int maxAttempts)
    {
        MaxAttempts = maxAttempts;
    }

    public override void BeforeInvoke(InterceptionContext context)
    {
        var policy = new RetryContext(MaxAttempts);
        context.Store("retry", policy);
    }

    public override void OnException(InterceptionContext context)
    {
        var policy = (RetryContext)context.Load("retry");
        if (policy.Attempt() < MaxAttempts)
        {
            context.Retry();
        }
    }
}

While seemingly elegant, this approach creates significant dependency management issues.

Dependency Injection Conflicts

Compile-time aspects cannot utilize constructor injection due to CLR attribute constraints. Alternative approaches introduce anti-patterns:

public class RetryPolicyAttribute : MethodInterceptionAspect
{
    public static IRetryStrategy Strategy { get; set; } // Ambient context anti-pattern
    
    public override void BeforeInvoke(InterceptionContext context)
    {
        Strategy?.Prepare(); // Null reference risk
    }
}

This static property creates temporal coupling, captive dependencies, and test contamination. Service locator patterns yield similar issues with additional indirection.

Compilation Coupling Problems

Aspects become permanently embedded in compiled code, eliminating flexibility during testing:

• Unit tests cannot isolate business logic from aspect behavior
• Integration tests require complex setup to accommodate mandatory aspects
• Caching or security aspects may interfere with test execution paths

This compile-time binding contradicts dependency inversion principles by hard-wiring volatile dependencies into the application structure. While useful for stable concerns, this approach fundamentally conflicts with proper dependency management for volatile components.