将Service变为Controller后，Caslte拦截器不再起作用
Closed this issue · 12 comments
希望指点一二。
我已经解决了，在你的博客上最后评论：https://www.cnblogs.com/stulzq/p/8547839.html
POCOController方式非常好，但是直接把Service变成Controller是不合理的，应该是创建一个Service代理类，将这个代理类变成Controller，这样才是合理的。
Service还是原来的Service，动态WebAPI是Service的代理类
并不赞同你的说法
不管是动态代理亦或是我这种方法，都是殊途同归，同样的效果，不存在对错，我这种方法对代码除了一个attribute没有任何侵入，可以说对代码的侵入可以忽略不计，并不会影响 service。而且这种方式是为了方便，提升效率，但不能完全替代 controller。
公开函数加 virtual 解决问题，如图：
没有说对错，只能说合不合理。您这种方式把Service变成了Controller，实际上这个Service变成了前端调用（API），也就是直接把Service公开出去了，但是集成了Caslte.DynamicProxy拦截器后，这个Service就不能应用EnableInterfaceInterceptors()了。比如我想实现工作单元，您那种方式只能把工作单元带到MVC的过滤器中写，但是对异步工作单元就做不到了。
公开函数加 virtual 解决问题，如图：
virtual确实是最快解决问题的，一开始就是这样解决的，但是这样的约束破坏了代码。
建议您去看一下 abp vnext
没有说对错，只能说合不合理。您这种方式把Service变成了Controller，实际上这个Service变成了前端调用（API），也就是直接把Service公开出去了，但是集成了Caslte.DynamicProxy拦截器后，这个Service就不能应用EnableInterfaceInterceptors()了。比如我想实现工作单元，您那种方式只能把工作单元带到MVC的过滤器中写，但是对异步工作单元就做不到了。
支持异步工作单元。使用 IAsyncFilter。
UnitOfWork异步工作单元
建议您去看一下 abp vnext
我就是看了Abp vnext之后，发现您代码和abp vnext几乎一致，我不否认abp vnext是优秀的框架，但是不能一味推崇，我也建议您去看看abp 旧版本，不是vnext版本，旧版本采用的是我现在的方式。
没有说对错，只能说合不合理。您这种方式把Service变成了Controller，实际上这个Service变成了前端调用（API），也就是直接把Service公开出去了，但是集成了Caslte.DynamicProxy拦截器后，这个Service就不能应用EnableInterfaceInterceptors()了。比如我想实现工作单元，您那种方式只能把工作单元带到MVC的过滤器中写，但是对异步工作单元就做不到了。
支持异步工作单元。使用 IAsyncFilter
您可以看看abp 工作单元原理。你在IAsyncFIilter中是如何处理ReturnValue的异步等待呢？
建议您去看一下 abp vnext
我就是看了Abp vnext之后，发现您代码和abp vnext几乎一致，我不否认abp vnext是优秀的框架，但是不能一味推崇，我也建议您去看看abp 旧版本，不是vnext版本，旧版本采用的是我现在的方式。
abp 老版本我用过，我知道，那是因为以前的core本身不支持这种方式，才使用的动态代理，而新版的core有了这种方式就立马切过来了，你觉得这是为什么
建议您去看一下 abp vnext
我就是看了Abp vnext之后，发现您代码和abp vnext几乎一致，我不否认abp vnext是优秀的框架，但是不能一味推崇，我也建议您去看看abp 旧版本，不是vnext版本，旧版本采用的是我现在的方式。
abp 老版本我用过，我知道，那是因为以前的core本身不支持这种方式，才使用的动态代理，而新版的core有了这种方式就立马切过来了，你觉得这是为什么
补充，Abp老版本分为.NET Framework和.NET Core的版本，.NET Core版本中动态WebAPI的实现和Panda.DynamicWebApi一致；Abp VNext沿用了老版本Abp .NET Core的实现