Linfu.dynamicproxy和Castle.dynamicproxy有什么区别?

我是Castle的提交者,为动态代理做出了贡献,所以我可能有偏见,但我一般认为Castle的动态代理是更好的解决方案。我在这里谈论的是Linfu DynamicProxy v1.0,因为这是我所熟悉的。代理2基于mono.cecil,从头重写。

• 城堡涵盖了更广泛的场景。
• Castle拥有(很多)更大的用户群,并且在许多OSS和商业应用中得到了证明。
• Castle实际上表现更好( link )
• Castle具有更清洁、更易于使用的API 例如,调用Target方法以Castle DynamicProxy如下所示:

invocation.Proceed();

对于Linfu,它看起来是这样的(实际的方法/属性名可能会随着我从内存中写入它而变化)

//invocation.TargetMethod is MethodInfo, so you're using reflection
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters);

• Castle有一个活跃的用户组,您可以在其中快速获得问题的答案。

另一个答案提到的性能问题不是动态氧气问题,而是微软BCL实现中的错误(在Mono上没有这样的问题btw)。 只有在单个moduleScope中有多个(超过200个)代理类型时,这一点才会显现出来。

解决方案很简单-不要生成那么多的代理类型(通常不必生成)或使用许多modulescope/proxygenerator(例如rhino.mocks使用此方法)

就我个人而言,我不在Mono上发展,所以我没有第一手的经验,但是有一些图书馆在Mono上使用Castle DP,我们没有任何合规性,所以我想它工作得很好。

自我几个月前的基准测试以来,Castle DP还没有新版本(新版本的目标是在今年年底)。李福有2.0版本,但我不确定它是仅行李箱还是释放的。我不知道春天和团结。

Linfu 是比Castle代理生成器更轻的代理生成器。

老实说,在决定使用哪一种时,没有什么区别。

据作者介绍,临福将大大优于城堡发电机,但在我对现实世界使用情况的观察中,速度的差异是微乎其微的。

说了林福会胜过城堡,我也不知道有什么城堡能胜过它,所以我总是用林福。

我们在2.0.1中遇到了一些关于临福和城堡的性能问题。 http://niemware.blogspot.com/2009/11/nhibernate-21-performance-issues-with.html