将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。
没有说对错,只能说合不合理。您这种方式把Service变成了Controller,实际上这个Service变成了前端调用(API),也就是直接把Service公开出去了,但是集成了Caslte.DynamicProxy拦截器后,这个Service就不能应用EnableInterfaceInterceptors()了。比如我想实现工作单元,您那种方式只能把工作单元带到MVC的过滤器中写,但是对异步工作单元就做不到了。
建议您去看一下 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的实现