4
votes

For an upcoming project I am planning to use both dependency injection and aspect oriented programming. I will implement the former by myself, following the DIY dependency injection guide and use LOOM.Net for the AOP part.

The common pattern to create an interweaved type of a logic class and an aspect class is

AspectClass aspect = new AspectClass();
LogicClass logic = Weaver.Create<LogicClass>(aspect);

My intuition would be to perform the interweaving in the glue code, e.g. for the classes ConcreteLogicA which implements ILogicA, which depends on ILogicB implemented by ConcreteLogicB

class MyInjector
{
    ...
    public ILogicA GetLogicA(AspectClass aspectToInterweave)
    {
        return Weaver.Create<ConcreteLogicA>(aspectToInterweave, GetLogicB(aspectToInterweave));
    }

    public ILogicB GetLogicB(AspectClass aspectToInterweave)
    {
        return Weaver.Create<ConcreteLogicB>(aspectToInterweave);
    }
    ...
}

Would this be a viable solution or is it way off the track. The advantage is, that I do not have to mix my logic with my aspects (which is sort of the clue of AOP, admittedly) but this way I am adding a bit more logic to the glue code.

2

2 Answers

4
votes

Since you are starting a new project, I would urge you to look more closely at the SOLID software design principles and try to apply them to your new project. When you designed your application using the right abstractions and conforming the SOLID principles, there's hardly ever a reason to use code weaving tools such as LOOM and PostSharp. Those tools are especially valuable if you're already in the unfortunate position that you have a legacy code base that you can't easily change.

Instead of using code weaving, let the design of your application lead you. When you design your application using the right abstractions, it would be easy to add cross-cutting concerns using decorators. You can find examples of systems that are designed using proper abstractions here and here.

Those articles describe how you define cross-cutting concerns using decorators. When you designed the system in this way, you can test the implementation of a cross-cutting concern separately from the rest of the code. Something that is much harder when using code weaving tools. This will be easy when using the right abstractions.

I've consulted several companies the last couple of years where I taught developers how to correctly apply design pattern with the benefit of improved flexibility and maintainability. Their legacy code bases made quite hard to achieve, but you seem to be in the fortunate position that you start a new project.

Use this as an opportunity to improve your design skills and allow your application to stay maintainable for years to come.

0
votes

I think that your problem can be solved by using dependency injection container that supports dynamic interception (most of them do). This repository demonstrates process of refactoring existing code towards aspects. It uses Castle Windsor DI container. The advantage of implementing aspects with dynamic interception instead of IL Weaving is that you can easily inject dependencies into your aspects and you do not need to rely on any ambient context/service locator.