将 DIY 依赖注入与面向方面编程相结合答案

【问题标题】：Combining DIY dependency injection with aspect oriented programming将 DIY 依赖注入与面向方面编程相结合
【发布时间】：2014-10-09 08:53:21
【问题描述】：

对于即将到来的项目，我计划同时使用依赖注入和面向方面的编程。我将自己实现前者，遵循DIY dependency injection guide 并使用LOOM.Net 作为AOP 部分。

创建逻辑类和方面类的交织类型的常用模式是

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

我的直觉是在胶水代码中执行交织，例如对于实现ILogicA的类ConcreteLogicA，它依赖于ConcreteLogicB实现的ILogicB

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

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

这是一个可行的解决方案，还是偏离正轨。优点是，我不必将我的逻辑与我的方面混合在一起（诚然，这是 AOP 的线索），但这样我在胶水代码中添加了更多逻辑。

【问题讨论】：

标签： c# dependency-injection aop rapier-loom

【解决方案1】：

由于您正在开始一个新项目，我建议您更仔细地查看SOLID 软件设计原则，并尝试将它们应用到您的新项目中。当您使用正确的抽象并符合 SOLID 原则来设计应用程序时，几乎没有理由使用 LOOM 和 PostSharp 等代码编织工具。如果您已经不幸地拥有无法轻易更改的遗留代码库，那么这些工具尤其有价值。

不要使用代码编织，而是让应用程序的设计引领您。当您使用正确的抽象设计应用程序时，使用装饰器添加横切关注点会很容易。您可以找到使用适当抽象 here 和 here 设计的系统示例。

这些文章描述了如何使用装饰器定义横切关注点。当您以这种方式设计系统时，您可以将横切关注点的实现与其余代码分开测试。使用代码编织工具时要困难得多。如果使用正确的抽象，这将很容易。

在过去的几年里，我咨询了几家公司，教开发人员如何正确应用设计模式，从而提高灵活性和可维护性。他们的遗留代码库很难实现，但您似乎很幸运能够开始一个新项目。

以此为契机，提高您的设计技能，并让您的应用程序在未来几年内保持可维护性。

【讨论】：

对我来说似乎很合理。无论如何，我还有一个问题：使用装饰器模式，我将不得不为每个接口实现一个方面类，不是吗？我还会在注入器中装饰我的逻辑类吗？如果我有LogicAAspect : ILogicA，我会在示例中使用return new LogicAAspect(new ConcreteLogicA(GetLogicB()))吗？
@PaulKertscher：我不确定我是否理解你的问题。我从不使用一些 DIY 的“注射器”。我要么使用real DI library，要么使用pure DI。当应用程序增长时，与纯 DI 或 DIY 相比，拥有 DI 库会非常有益。拥有装饰器的最大优势在于，这些装饰器可以拥有自己的依赖项，并且装饰器实现完全不依赖任何外部工具，例如拦截库或 AOP 框架。

【解决方案2】：

我认为您的问题可以通过使用支持动态拦截的依赖注入容器来解决（大多数都这样做）。 This 存储库演示了将现有代码重构为方面的过程。它使用 Castle Windsor DI 容器。使用动态拦截而不是 IL Weaving 实现方面的优势在于，您可以轻松地将依赖项注入到方面，并且不需要依赖任何环境上下文/服务定位器。

【讨论】：