PROSAGA码农传奇-SF服务编织-使用编译时编织的依赖注入？

<div class =“post-text”itemprop =“text”>
  
    我不认为你在这里遗漏任何东西，而且限制确实是使用编译时编织的结果。
  
  
    虽然我认为编译时编织工具在软件开发中占有一席之地，但我觉得它们经常被过度使用。我经常看到它们被用来修补应用程序设计中的缺陷。在我构建的应用程序中，我将通用接口应用于某些架构概念。例如，我定义：
  
  <UL>
    <LI>
      一个
       <code>
 ICommandHandler<TCommand>
 </code>
       实现某个用例的服务的接口;
    </LI>
    <LI>
      一个
       <code>
 IQueryHandler<TQuery, TResult>
 </code>
       执行查询的服务的接口;
    </LI>
    <LI>
      一个
       <code>
 IRepository<TEntity>
 </code>
       接口作为存储库的抽象;
    </LI>
    <LI>
      一个
       <code>
 IValidator<TCommand>
 </code>
       执行消息验证的组件的接口;
    </LI>
    <LI>
      等等等等。
    </LI>
  </UL>
  
    这允许我为这样的工件组创建一个通用装饰器（例如
     <code>
 TransactionCommandHandlerDecorator<TCommand>
 </code>
     允许在自己的事务中运行每个用例）。装饰器的使用具有许多优点，例如：
  
  <UL>
    <LI>
      这些通用装饰器完全与工具无关，因为没有对代码编织工具或拦截库的引用。 PostSharp方面完全依赖于PostSharp，拦截器总是依赖于拦截框架，例如Castle.DynamicProxy。
    </LI>
    <LI>
      因为装饰器只是一个普通的组件，所以可以将依赖关系注入到构造函数中，并且在使用依赖注入组合对象图时它们可以起到正常作用。
    </LI>
    <LI>
      装饰器代码非常干净，因为缺乏与任何第三方工具的依赖关系。
    </LI>
    <LI>
      因为它们与工具无关并且允许依赖注入，所以装饰器可以轻松地进行单元测试，而不必回复特殊技巧。
    </LI>
    <LI>
      需要应用横切关注点的应用程序代码也可以单独进行测试，因为装饰器不会在编译时编织。在编译时编译装饰器时，您总是被迫执行应用程序代码测试的集成方式，或者需要恢复特殊构建技巧以防止它们应用于单元测试项目中。
    </LI>
    <LI>
      装饰器可以在运行时动态地和有条件地应用，因为没有编译时代码编织。
    </LI>
    <LI>
      性能与代码编织相同（甚至更快），因为在对象构造期间没有反射。
    </LI>
    <LI>
      没有必要使用属性标记组件，以指出必须应用某些方面。这可以使您的应用程序代码不受任何关于这种交叉问题的了解，并且可以更容易地替换它。
    </LI>
  </UL>
  
    关于这种应用程序设计已经写了很多;以下是我自己撰写的一些文章：
  
  <UL>
    <LI>
      <a href="https://blogs.cuttingedge.it/steven/posts/2011/meanwhile-on-the-command-side-of-my-architecture/" rel="nofollow noreferrer">
        同时......在我的架构的命令方面
      </A>
    </LI>
    <LI>
      <a href="https://blogs.cuttingedge.it/steven/posts/2011/meanwhile-on-the-query-side-of-my-architecture/" rel="nofollow noreferrer">
        同时......在我的架构的查询方面
      </A>
    </LI>
    <LI>
      <a href="https://blogs.cuttingedge.it/steven/posts/2012/writing-highly-maintainable-wcf-services/" rel="nofollow noreferrer">
        编写高度可维护的WCF服务
      </A>
    </LI>
    <LI>
      第10章，
      
        面向方面的设计编程
      
      ，我的书
      <a href="https://manning.com/seemann2" rel="nofollow noreferrer">
        依赖注入原则，实践，模式
      </A>
       包含对此类设计的非常详细的讨论。
    </LI>
  </UL>
  
    
      UPDATE
    
  
  <BLOCKQUOTE>
    
      装饰器很棒，但我喜欢的AOP是它的概念
  建议和加入点。有没有办法模拟相同的功能
  与装饰？我现在只能想到反思。
    
  </BLOCKQUOTE>
  
    一个
    的
      加入点
    </强>
     是一个“在一个关注将要附加的类中明确定义的位置”。使用装饰器应用AOP时，您将“限制”加入方法边界上的点。但是，如果你坚持
    <a href =“https：//en.wikipedia.org / wiki / Single_responsibility_principle“rel =”nofollow noreferrer“>
      SRP
    </A>
    ，
    <a href="https://en.wikipedia.org/wiki/Open/closed_principle" rel="nofollow noreferrer">
      OCP
    </A>
     和
    <a href="https://en.wikipedia.org/wiki/Interface_segregation_principle" rel="nofollow noreferrer">
      ISP
    </A>
    ，你将拥有非常薄的接口（通常使用单一方法）。这样做时，您会注意到几乎没有理由在您的班级中的任何其他地方设置加入点。
  
  
    一个
    的
      忠告
    </强>
     是“可能会改变目标方法的输入和/或输出的关注点”。当使用装饰器和基于消息的设计（我在这里宣传的东西）时，您的建议需要更改消息（或用更改的值替换完整的消息）或更改输出值。事情与代码编织没什么不同 如果您应用建议，则应用建议的所有代码之间必须存在共同点。
  
</DIV>