Spring.Net能像PostSharp一样工作吗？

几个月前，我发现了PostSharp，有一段时间，它很好

但随后，法务部回复说，他们不喜欢旧版本的许可证。然后部门告诉我2.0的价格高得令人无法接受（就我们需要的座位数量而言）。。。我非常失望，但并不气馁。我想，这不可能是唯一这样的框架

我一直在寻找一个替代品，但其中大部分要么是死的，要么是维护不良（尤其是在文档部门），要么是学术用途，要么是以上所有的（我在关注你的Aspect.Net）

后来我发现了Spring.Net，它一度很好

我一直在阅读文档，它接着描绘了一幅似乎是AOP涅盘的超级图片。我不再被锁定到属性来标记我希望代码截取发生的位置，但它可以在XML中配置，对它的更改不需要重新编译。太好了

然后我查看了这些示例，并在每个使用场景中看到了以下内容：

// Create AOP proxy using Spring.NET IoC container.
IApplicationContext ctx = ContextRegistry.GetContext();
ICommand command = (ICommand)ctx["myServiceCommand"];    
command.Execute();
if (command.IsUndoCapable)
{
    command.UnExecute();
}

为什么前两行代码必须存在？它会毁掉一切。这意味着我不能简单地向用户提供一组方面和属性或XML配置，用户可以通过在适当的方法/类/etc上粘贴适当的属性或编辑XML中的匹配模式来使用这些方面和属性或XML配置。他们必须修改他们的程序逻辑，以使这项工作

在这种情况下，有没有办法让Spring.Net像PostSharp一样工作？（即用户只需添加attributes/XML config，不需要编辑任何方法的内容

---

或者，是否有一个有价值且功能强大的PostSharp替代品？我在上面看到了一些题为“这样”的问题，但没有一个真正想取代PostSharp，他们只是想补充它的功能。我需要完全取代它。

简言之，是的，Spring.Net AOP可以按照您描述的使用基于XML的c的方式工作配置：您不必使用最初的两行代码，事实上不鼓励基于代码的配置。您可以仅使用基于XML的配置来配置Spring.Net AOP，这实际上是推荐的方法

为此，有几个步骤：

创建您的建议：BeforeAdvice、AroundAdvice、AfterReturningAdvice和ThrowAdvice是受支持的建议类型。AroundAdvice使用AOPAlliance接口，其他使用Spring.AOP接口

定义切入点

应用切入点和建议

配置示例（从实时配置中概括）：

*命令
...
在顾问之前
返回遮阳板
throwsAdvisor

编织是在运行时执行的，速度非常快且不具侵扰性

希望这是有用的

---

安德鲁

我想你正在寻找这个功能

您已在开始时的某个位置加载了Spring.NET应用程序上下文。基于代码的依赖关系对Spring.NET的依赖性很小。问题是，无论您在哪里需要（adviced）服务，您都会使用ContextRegistry.GetContext（）显式依赖Spring.NET

您可以通过使用查找方法替换方法来解决此问题，例如：

创建一个AbstractCommandFactory：

namespace MyNamespace {
  public abstract class AbstractCommandFactory : ICommandFactory {
    public abstract ICommand getMyCommand();  
  }
}

使用Spring.NET，您可以获取MyCommand并返回Spring.NET对象：

<objects>
  <object id="commandfactory"
          type="MyNamespace.AbstractCommandFactory, MyAssembly">
    <lookup-method name="getMyCommand" object="commands.mycommand" />
  </object>

  <object id="commands.mycommand" 
          type=MyNamespace.MyCommandImplementation, MyAssembly" />
</objects>

现在，您对Spring.NET的显式依赖非常小：仅在工厂的初始加载+实例化时，其余代码保持干净

---

优点：您可以更轻松地创建ICommandFactory/ICommand Mock来对代码进行单元测试。

简短的回答是否定的，因为PostSharp实际上是在构建后的步骤中重写代码。不过，我会让Spring专家参与进来；我知道，如果您使用DI来实例化您的服务，并且愿意涉猎方法int，您可以非常接近感知。见鬼，我完全支持重新编写！我甚至会自己做需要的事情。如果CCI-AST的文档记录得足够好，或者至少它的示例代码是功能性的和足够多样的>\u>还有什么可以满足我在这方面的需要吗？也许你可以更具体地说明你在尝试做什么，以及在哪里找到这个示例？我不知道正如我已经提到的，关于Spring的内容很多，但我确实对它进行了一次评估，不记得必须在类中嵌入任何

ICommand

内容才能使用建议系统。这些代码直接来自Spring.Net 1.3安装中的Examples文件夹。ICommand不是问题（基本上是他们的示例“do work”接口，从中派生实际工作类）。这些东西已经存在于客户端的代码中。问题在于IApplicationContext的东西。这是Spring特有的，每个使用它的人都必须修改他们想要在其中创建命令对象的每个函数…这是不可接受的部分。你说PostSharp的价格太高了。与什么相比呢？如果你真的需要它，你应该我可以向你的经理证明价格是合理的，因为x、y、z等原因。如果我真的坚信Postsharp对项目的成功至关重要，我会这么做。否则你的经理是正确的，你不必要地花钱而没有真正的利益。我经常看到这种争论，没有适当的price效益评估。这是对IT项目的总体评论。一篇博客文章简要介绍了AOP的总体情况：

<objects>
  <object id="commandfactory"
          type="MyNamespace.AbstractCommandFactory, MyAssembly">
    <lookup-method name="getMyCommand" object="commands.mycommand" />
  </object>

  <object id="commands.mycommand" 
          type=MyNamespace.MyCommandImplementation, MyAssembly" />
</objects>

public void doSomeWork() {
  // factory is an ICommandFactory
  // instantiated earlier using the explicit context.getObject("commandfactory")
  ICommand myCommand = this.factory.getMyCommand();
  myCommand.Execute();
}