c# - Spring.NET AOP 代理和 MS WebAPI Controller

Question

我将 MS WebAPI 与 Spring.NET 一起用于我的 DI，并使用 Sprint.NET AOP 将方法标记为事务性。

当我将“ Controller ”操作标记为事务性操作时，出现以下错误:

无法将类型为“CompositionAopProxy_13695853c76b40f8b9436e27afa947f0”的对象转换为类型“TPMarketing.PayrollConsole.Web.Rest.Controllers.OrganisationsController”。对象，对象[])\r\n 在 System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c_DisplayClass13.b_c(对象实例，对象[] 方法参数)\r\n在 System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(对象实例，对象 [] 参数)\r\n 在 System.Web.Http.Controllers.ReflectedHttpActionDescriptor.<>c_DisplayClass5.b_4()\r\n 在 System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)

这是否意味着您不能将基于代理的 AOP 与 Web API Controller 一起使用？

(我有一个解决方法，我已经为继承自 ActionFilterAttribute 的属性创建了自己的“Transaction”属性，以便仅在 Web 层中使用)

谢谢，乔丹。

编辑...我还没有时间查看下面的 Marijns 建议，所以这里是我为任何感兴趣的人提供的解决方法。这是我的 Action Filter 中的代码主体:(TransactionManager 是 Spring.NET IPlatformTransactionManager)。我仍在我的服务层中使用普通的 Spring.NET Transaction 属性，这应该能很好地配合它。

    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.ReadOnly = ReadOnly;
        actionContext.Request.Properties[TRANSACTION_KEY] = TransactionManager.GetTransaction(def);
    }


    public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        ITransactionStatus ts = actionExecutedContext.Request.Properties[TRANSACTION_KEY] as ITransactionStatus;
        if (ts.RollbackOnly || actionExecutedContext.Exception != null)
        {
            TransactionManager.Rollback(ts);
        }
        else
        {
            TransactionManager.Commit(ts);
        }
    }

    public bool ReadOnly { get; set; }

Answer 1

CopositionAopProxy 是基于契约的，是你的接口(interface)的一个实现，并且不能转换到你的类，因为它不是你的类的继承，代理包含你的类的一个实例，作为一个属性，但只实现相同的接口(interface)你的类(class)。

看AOP documentation :

13.1.3. AOP Proxies in Spring.NET

Spring.NET generates AOP proxies at runtime using classes from the System.Reflection.Emit namespace to create necessary IL code for the proxy class. This results in proxies that are very efficient and do not impose any restrictions on the inheritance hierarchy.

Another common approach to AOP proxy implementation in .NET is to use ContextBoundObject and the .NET remoting infrastructure as an interception mechanism. We are not very fond of ContextBoundObject approach because it requires classes that need to be proxied to inherit from the ContextBoundObject either directly or indirectly. In our opinion this an unnecessary restriction that influences how you should design your object model and also excludes applying AOP to "3rd party" classes that are not under your direct control. Context-bound proxies are also an order of magnitude slower than IL-generated proxies, due to the overhead of the context switching and .NET remoting infrastructure.

Spring.NET AOP proxies are also "smart" - in that because proxy configuration is known during proxy generation, the generated proxy can be optimized to invoke target methods via reflection only when necessary (i.e. when there are advices applied to the target method). In all other cases the target method will be called directly, thus avoiding performance hit caused by the reflective invocation.

Finally, Spring.NET AOP proxies will never return a raw reference to a target object. Whenever a target method returns a raw reference to a target object (i.e. "return this;"), AOP proxy will recognize what happened and will replace the return value with a reference to itself instead.

The current implementation of the AOP proxy generator uses object composition to delegate calls from the proxy to a target object, similar to how you would implement a classic Decorator pattern. This means that classes that need to be proxied have to implement one or more interfaces, which is in our opinion not only a less-intruding requirement than ContextBoundObject inheritance requirements, but also a good practice that should be followed anyway for the service classes that are most common targets for AOP proxies. In a future release we will implement proxies using inheritance, which will allow you to proxy classes without interfaces as well and will remove some of the remaining raw reference issues that cannot be solved using composition-based proxies.