LinFu.DynamicProxy和Castle.DynamicProxy有什么区别？ [英] What are the differences between LinFu.DynamicProxy and Castle.DynamicProxy?

问题描述

我正在考虑向正在使用的库添加逻辑，这将需要动态代理。我想从在生产环境中使用过这两个库的用户那里获取一些建议。一个会执行其他操作吗，是否有任何缺点导致您不得不切换到另一个，等等。基本上告诉我您使用图书馆的经验。答案将帮助我决定使用哪个。

I am looking at adding logic to a library I am working on that would require the need for a Dynamic Proxy. I would like to get some advice from user's who have used these two library's in a production environment. Does one out perform the other, were there any shortcoming's which made you have to switch to the other, etc. Basically tell me your experiences with the library's. The answers will help me decide which one to use.

-编辑-

我忘了提到我正在开发的库将支持Mono，因此，您可以共享的关于这两个库的任何知识以及它们对Mono的支持也将很棒。

I forgot to mention that the library I am developing will support Mono, therefore any knowledge you can share about the two libraries and their support for Mono would be great also.

推荐答案

我是Castle的提交者，为Dynamic Proxy做出了贡献，因此我可能会有偏见，但我通常认为Castle的Dynamic proxy是更好的解决方案。我在这里谈论的是LinFu DynamicProxy v1.0，因为这是我所熟悉的。 LinFu.Proxy 2基于Mono.Cecil，并且从头开始进行了重写。

I am a committer to Castle, contributing to Dynamic Proxy, so I may be biased, but I generally think Castle's Dynamic proxy is far better solution. I'm talking here about LinFu DynamicProxy v1.0 because that's what I'm familiar with. LinFu.Proxy 2 is based on Mono.Cecil and is rewritten from the scratch.

• 城堡涵盖了更多的场景。


• 城堡有（很多）更大的用户群，并在许多OSS和商业应用中得到了证明


• 城堡实际上表现更好（链接）


• 城堡具有更清洁，更易于使用的API
  例如，将目标方法调用给Castle DynamicProxy如下：

• Castle covers wider range of scenarios.
• Castle has (a lot) larger user base, and is proven in many OSS and commercial applications
• Castle is actually performing better (link)
• Castle has cleaner, easier to use API for example invoking target method to Castle DynamicProxy looks like this:

invocation.Proceed（）;

对于LinFu，它看起来像这样（实际的方法/属性名称可能会随我所写而变化

for LinFu, it looks like this (actual method/property name may vary as I'm writing it from memory)

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

• 城堡有一个活跃的用户组，您可以在其中快速找到自己的答案问题。



另一个答案提到的性能问题不是DynamicProxy问题，而是Microsoft实施BCL中的错误的结果（在Mono上，没有此类问题）。
仅当您在单个ModuleScope中具有许多（超过200种以上）代理类型时才会显示出来。

The performance issue, mentioned by the other answer are not DynamicProxy issue, but are result of bug in Microsoft's implementation of BCL (on Mono there is no such issue BTW). This only manifests itself when you have many (over 200+) proxy types in single ModuleScope.

解决方案很简单-不要生成那么多代理类型（通常您不必）或使用许多ModuleScopes / ProxyGenerators（例如Rhino.Mocks使用这种方法）

Solution is trivial - don't generate that many proxy types (usually you won't have to) or use many ModuleScopes/ProxyGenerators (for example Rhino.Mocks uses this approach)

我个人不是在Mono上开发，所以我没有第一手经验，但是有一些图书馆在Mono上使用Castle DP，我们没有任何抱怨，所以我想它很好用。

Personally I do not develop on Mono, so I don't have firsthand experience, however there are libraries using Castle DP on Mono, and we didn't get any compliaints so i guess it works just fine.

基准几个月前，还没有新版本的Castle DP（新版本将在今年年底推出）。 LiFu具有2.0版本，但是我不确定它是仅中继还是已发布。我不了解Spring或Unity。

Since my benchmark few months ago, there has been no new release of Castle DP (new version is targeted at the end of the year). LiFu has a 2.0 version, but I'm not sure if it is trunk only, or released. I don't know about Spring or Unity.

这篇关于LinFu.DynamicProxy和Castle.DynamicProxy有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！