LinFu.DynamicProxy 和 Castle.DynamicProxy 有什么区别？
我正在考虑向我正在开发的库添加逻辑，这需要动态代理。我想从在生产环境中使用过这两个库的用户那里得到一些建议。其中一个是否优于另一个，是否有任何缺点使您不得不切换到另一个，等等。基本上告诉我您对图书馆的体验。答案将帮助我决定使用哪一个。
-- 编辑 --
我忘了提及我正在开发的库将支持 Mono，因此您可以分享有关这两个库及其对 Mono 的支持的任何知识也会很棒。
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.
-- Edit --
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们在 2.0.1 中遇到了一些与 LinFu 与 Castle 相关的性能问题。 http://niemware.blogspot.com/2009/ 11/nhibernate-21-performance-issues-with.html
We had some perf issues related to LinFu vs Castle in 2.0.1. http://niemware.blogspot.com/2009/11/nhibernate-21-performance-issues-with.html
我是 Castle 的提交者，为动态代理做出贡献，所以我可能有偏见，但我通常认为 Castle 的动态代理是更好的解决方案。我在这里谈论LinFu DynamicProxy v1.0，因为这是我所熟悉的。 LinFu.Proxy 2基于Mono.Cecil并从头开始重写。
例如，调用 Castle DynamicProxy 的目标方法如下所示：
invocation.Proceed();对于 LinFu，它看起来像这样（实际方法/属性名称可能会有所不同，因为我是凭记忆编写的）
其他答案提到的性能问题不是 DynamicProxy 问题，而是 Microsoft 的 BCL 实现中的错误导致的（顺便说一句，在 Mono 上没有这样的问题）。
仅当您在单个 ModuleScope 中有许多（超过 200 多个）代理类型时，这一点才会显现出来。
解决方案很简单 - 不要生成那么多代理类型（通常不需要）或使用许多 ModuleScopes/ProxyGenerators（例如 Rhino.Mocks 使用这种方法）
我个人不在 Mono 上开发，所以我不有第一手经验，但是有一些库在 Mono 上使用 Castle DP，并且我们没有得到任何兼容，所以我想它工作得很好。
自从我几个月前进行基准测试以来，Castle DP 还没有新版本发布（新版本目标是在今年年底发布）。 LiFu有2.0版本，但我不确定它是仅主干还是已发布。我不知道 Spring 或 Unity。
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.
for example invoking target method to Castle DynamicProxy looks like this:
invocation.Proceed();for LinFu, it looks like this (actual method/property name may vary as I'm writing it from memory)
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.
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)
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.
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 是一个比 Castle 代理生成器更轻量级的代理生成器。
老实说，在决定使用哪个时，没有太大区别。
根据作者的说法，Linfu 将大大优于 Castle 生成器，但根据我自己对现实世界使用情况的观察，速度差异微乎其微。
话虽如此，Linfu会胜过Castle，但我不知道Castle有什么比它更好的，所以我总是使用Linfu。
Linfu is a more lightweight proxy generator than the Castle proxy generator.
When deciding which to use, to be honest it doesn't make much difference.
According to the author, Linfu will greatly outperforms the Castle generator, but in my own observations of real world usage the difference in speed is marginal.
Having said that Linfu will outperform Castle, and I'm not aware of anything Castle has over it, and so I always use Linfu.