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

问题描述：

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

共用图案创建交织的类型逻辑类和一个方面类是

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

我的直觉。将在胶水代码执行交织，例如对于类ConcreteLogicA它实现ILogicA，这取决于ILogicB通过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); 
    } 
    ... 
}

实施这将是一个可行的解决方案或者是它的方式离开了赛场。好处是，我不必将自己的逻辑与我的方面混合在一起（这是AOP的线索），但这样我就为胶水代码添加了更多的逻辑。

答

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

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

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

在过去几年里，我教过几家公司，教会开发人员如何正确应用设计模式，并提高灵活性和可维护性。他们的遗留代码库很难实现，但你似乎处于幸运的位置，即你开始一个新项目。

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

对我来说似乎很合理。无论如何，我还有一个问题：使用装饰模式，我将不得不在每个接口上实现一个方面类，不是吗？我仍然会在注射器中装饰我的逻辑类吗？如果我有'LogicAAspect：ILogicA'，我会在示例中返回新的LogicAAspect（新的ConcreteLogicA（GetLogicB（）））吗？ – 2014-10-09 10:55:24

@PaulKertscher：我不知道我理解你的问题。我从来没有与一些DIY“注射器”合作。我要么使用[真正的DI库]（https：// simpleinjector。org）或者我使用[pure DI]（http://blog.ploeh.dk/2014/06/10/pure-di/）。当应用程序增长时，与纯DI或DIY相比，拥有DI库会非常有益。装饰器的巨大优势在于，那些装饰器可以拥有自己的依赖关系，而装饰器实现完全没有任何外部工具，比如拦截库或AOP框架。 – Steven 2014-10-09 11:14:04

答

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

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

相关推荐