Каковы различия между LinFu.DynamicProxy и Castle.DynamicProxy? - PullRequest
Новая
       31

Каковы различия между LinFu.DynamicProxy и Castle.DynamicProxy?

30 голосов
/ 10 сентября 2009

Я смотрю на добавление логики в библиотеку, над которой я работаю, что потребует наличия динамического прокси. Я хотел бы получить совет от пользователя, который использовал эти две библиотеки в производственной среде. Выполняет ли один другой другой, были ли какие-то недостатки, из-за которых вам приходилось переключаться на другие и т. Д. В основном, расскажите мне о своем опыте работы с библиотекой. Ответы помогут мне решить, какой из них использовать.

- Правка -

Я забыл упомянуть, что библиотека, которую я разрабатываю, будет поддерживать Mono, поэтому любые знания, которыми вы можете поделиться о двух библиотеках и их поддержке Mono, также были бы хорошими.

Ответы [ 3 ]

20 голосов
/ 10 сентября 2009

Я приверженец Касла, участвующий в работе Динамического прокси, поэтому я могу быть предвзятым, но в целом я считаю, что Динамический прокси Касла является гораздо лучшим решением. Я говорю здесь о LinFu DynamicProxy v1.0, потому что это то, с чем я знаком. LinFu.Proxy 2 основан на Mono.Cecil и переписан с нуля.

  • Замок охватывает более широкий спектр сценариев.
  • Castle имеет (намного) большую пользовательскую базу, и доказано во многих OSS и коммерческих приложениях
  • Замок на самом деле работает лучше ( ссылка )
  • Замок имеет более чистый, простой в использовании API например, вызов целевого метода для Castle DynamicProxy выглядит следующим образом:

invocation.Proceed();

для LinFu это выглядит так (реальное имя метода / свойства может отличаться, поскольку я пишу его из памяти) 

//invocation.TargetMethod is MethodInfo, so you're using reflection
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters);
  • В замке есть активная группа пользователей, где вы можете быстро получить ответы на свои вопросы.

Проблема производительности, упомянутая в другом ответе, не является проблемой DynamicProxy, но является результатом ошибки в реализации Microsoft BCL (в Mono такой проблемы нет, BTW). Это проявляется только тогда, когда у вас есть много (более 200) типов прокси в одном ModuleScope.

Решение тривиально - не генерируйте столько прокси-типов (обычно вам это не нужно) или используйте много ModuleScopes / ProxyGenerators (например, Rhino.Mocks использует этот подход)

Лично я не занимаюсь разработкой на Mono, поэтому у меня нет опыта из первых рук, однако есть библиотеки, использующие Castle DP на Mono, и у нас не было никаких жалоб, поэтому я думаю, что это работает просто отлично.

Со времени моего теста несколько месяцев назад не было выпущено нового выпуска Castle DP (новая версия запланирована на конец года). У LiFu есть версия 2.0, но я не уверен, что она только магистральная или выпущена. Я не знаю о Весне или Единстве.

10 голосов
/ 10 сентября 2009

Linfu является более легким прокси-генератором, чем прокси-генератор Castle.

При принятии решения, какой из них использовать, честно говоря, это не имеет большого значения.

По словам автора, Линфу значительно превосходит генератор Касла, но в моих собственных наблюдениях использования реального мира разница в скорости незначительна.

Сказав, что Линьфу превзойдет Касла, я не знаю ничего, что Касл имеет над этим, и поэтому я всегда использую Линфу.

4 голосов
/ 18 ноября 2009

У нас были некоторые проблемы, связанные с LinFu vs Castle в 2.0.1. http://niemware.blogspot.com/2009/11/nhibernate-21-performance-issues-with.html

...