2009-09-10 11 views
30

Sto cercando di aggiungere la logica a una libreria su cui sto lavorando che richiede la necessità di un proxy dinamico. Vorrei avere qualche consiglio da parte degli utenti che hanno usato queste due librerie in un ambiente di produzione. L'uno esegue l'altro, ci sono dei difetti che ti hanno costretto a passare all'altro, ecc. Fondamentalmente dimmi le tue esperienze con quelle della biblioteca. Le risposte mi aiuteranno a decidere quale usare.Quali sono le differenze tra LinFu.DynamicProxy e Castle.DynamicProxy?

- Modifica -


Ho dimenticato di dire che la biblioteca sto sviluppando sosterrà Mono, quindi, alcuna conoscenza è possibile condividere sui due biblioteche e il loro sostegno per Mono sarebbe grande anche.

risposta

20

Sono un committer a Castle, che contribuisce a Dynamic Proxy, quindi potrei essere di parte, ma generalmente penso che il proxy di Castle's Dynamic sia una soluzione di gran lunga migliore. Sto parlando di LinFu DynamicProxy v1.0 perché è quello che mi è familiare. LinFu.Proxy 2 è basato su Mono.Cecil e viene riscritto da zero.

  • Castello copre una gamma più ampia di scenari.
  • Castello ha (molto) più grande base di utenti, ed è dimostrato in molte applicazioni commerciali OSS e
  • Castello è in realtà andando meglio (link)
  • Castello ha più pulita, più facile da usare API per esempio invocando il metodo di destinazione al Castello di DynamicProxy assomiglia a questo:

invocation.Proceed();

per Linfu, sembra che questo (vero nome del metodo/proprietà può variare come sto scrivendo dalla memoria)

//invocation.TargetMethod is MethodInfo, so you're using reflection 
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters); 
  • Castello ha un gruppo utente attivo dove è possibile ottenere velocemente le risposte alle vostre domande.

Il problema di prestazioni, menzionato dall'altra risposta, non è un problema di DynamicProxy, ma è il risultato di un bug nell'implementazione di BCL da parte di Microsoft (su Mono non esiste tale problema BTW). Questo si manifesta solo quando si hanno molti (oltre 200) tipi di proxy in un singolo ModuleScope.

La soluzione è banale: non generare molti tipi di proxy (in genere non è necessario) o utilizzare molti ModuleScopes/ProxyGenerators (ad esempio Rhino.Mazzi usa questo approccio)

Personalmente non sviluppo su Mono, quindi non ho esperienza diretta, tuttavia ci sono librerie che usano Castle DP su Mono, e non abbiamo ricevuto alcun complias quindi credo che funzioni solo bene.

Dal mio benchmark pochi mesi fa, non c'è stata alcuna nuova versione di Castle DP (la nuova versione è destinata alla fine dell'anno). LiFu ha una versione 2.0, ma non sono sicuro che sia solo trunk o rilasciato. Non so di Primavera o Unità.

+0

@Krzysztof - Grazie per il link sui test delle prestazioni che hai eseguito. Vedo che i test sono stati circa 6 mesi fa. Hai provato a eseguire nuovamente i test con le ultime versioni di ogni framework? Non sono sicuro se ci siano state nuove versioni da allora. Inoltre, ho dimenticato una cosa nella mia domanda e l'ho modificata. Potresti modificare la tua risposta per includere i test di qualsiasi esperienza con Mono? –

+0

Ho eseguito test di Dynamic Proxy (trunk) contro la versione 2.1. Mentre i tempi di intercettazione non sono cambiati (e funziona ** molto ** velocemente) la generazione del tipo di proxy è ora più volte più veloce –

+0

@ KrzysztofKoźmic, quale sarebbe la tua raccomandazione attuale tra Castle e Lin Fu? – smartcaveman

10

Linfu è un generatore di proxy più leggero rispetto al generatore di proxy Castle.

Al momento di decidere quale utilizzare, per essere onesti non fa molta differenza.

Secondo l'autore, Linfu supererà di gran lunga il generatore del castello, ma nelle mie osservazioni sull'utilizzo del mondo reale la differenza di velocità è marginale.

Detto questo, Linfu supererà le prestazioni di Castle e non sono a conoscenza di nulla che Castle abbia su di esso, quindi utilizzo sempre Linfu.

+1

Cosa intendi per "leggero"? –

+1

Con il peso leggero intendo meno codice, assemblaggio più piccolo e (OK, probabilmente a seconda di come lo si usa) più veloce. – Cocowalla

+0

@Cocowalla - Stai utilizzando l'ultima versione basata su Mono.Cecil. Inoltre, puoi condividere esperienze con LinFu in Mono? –

Problemi correlati