Dove e come utilizzare gli intercettatori nell'applicazione Web?

Question

Sono interessato al concetto di intercettore negli ultimi tempi. So che questo concetto è usato in molte librerie come NHibernate, Entity Framework e altre. Ma sono interessato a come utilizzare questo concetto nell'applicazione Web ASP.NET MVC.

Dove è utile utilizzarlo nell'applicazione Web Mvc?

Esiste un progetto Asp.Net Mvc open source che utilizza gli intercettori?

Asp.net Mvc supporta già un tipo di intercettore per controller con filtri. È meglio usare i filtri anziché gli intercettori?

Answer 1

Direi che usi un contenitore DI più generico per iniettare le tue dipendenze. Non solo inietta le dipendenze nel controller, ma anche le dipendenze di tali dipendenze, risultando in un grafico completo di tutti gli oggetti dipendenti.

L'utilizzo di un contenitore DI per il front-end offre anche buone opportunità per rendere il vostro back-end più testabile e accoppiato liberamente.

Answer 2

intercettazione può essere utilizzato per molte cose - più importanti per affrontare le preoccupazioni trasversali quali strumentazione, logging, auditing, sicurezza, misurazione, ecc

È don't need a DI Container to apply the concept, ma aiuta.

È possibile utilizzare i filtri ASP.NET MVC per ottenere circa lo stesso effetto, ma perché limitarsi al framework MVC quando è possibile applicare un'implementazione generalmente riutilizzabile?

Answer 3

Dove/quando utilizzare intercettori

Date un'occhiata a una precedente domanda aver sviluppato ed esaminare il codice. Cerca il codice che viene spesso duplicato all'inizio o alla fine di metodi e proprietà. Questo è il codice che potresti considerare di passare da tutti questi metodi a un intercettore. Per esempio, ho notato che molte delle mie azioni MVC che eseguono la convalida dell'input lo fanno con le stesse medesime paio di righe di codice:

if (!ModelState.IsValid) 
    return View(model); 

Questo è il codice che potrebbe potenzialmente essere spostato in un intercettore (probabilmente un filtro MVC in questo caso). Il costo di scrittura e applicazione del filtro supera il costo di questo codice duplicato? (2 righe di codice moltiplicano il numero di azioni del controller che utilizzano questo). In questo caso, forse no. Ci sono altre situazioni, tuttavia, in cui il vantaggio di usare un intercettore sarebbe maggiore.

Ecco un elenco di alcune situazioni in cui immagino che questo tipo di duplicazione del codice potrebbe verificarsi, ad esempio scenari che odore come potrebbero beneficiare di intercettori:

• di convalida dell'input (come illustrato sopra).
• Registrazione di debug. Si potrebbe write an interceptor che registra l'ingresso e l'uscita di ogni chiamata di metodo.
• Sincronizzazione del filo. La tua domanda riguarda le app Web, ma se stai sviluppando un'applicazione Windows con una vista in stile MVP, puoi applicare un intercettore che assicuri che tutte le chiamate ai metodi siano sincronizzate al thread dell'interfaccia utente.
• Transazioni di database. La maggior parte del mio database codice di transazione si presenta così:

 

using (var transaction = Session.BeginTransaction()) 
{ 
    // ... do some work that is unique to this method ... 
    transaction.Commit(); 
} 

• implementazioni di eventi PropertyChanged. Questo codice è in genere molto ripetitivo e fastidioso da scrivere. Sacha Barber has thoroughly explored how to automatically implement this event using various frameworks.
• Sicurezza. Ci sono probabilmente molti metodi nella vostra applicazione che dovrebbero essere limitati solo a determinati utenti. The AuthorizeAttribute è un filtro esattamente per questo.
• Servizio Web per la limitazione della richiesta. Alcune API, come l'API per Basecamp, ti richiedono limit your requests per un certo numero di richieste per un determinato periodo di tempo. Se hai scritto una classe client Basecamp, potresti applicare un intercettore per assicurarsi che tutte le chiamate al metodo rispettino il limite di velocità, utilizzando Thread.Sleep quando necessario.
• Nascondere nella cache.MVC has some filters pre-built for this purpose. È possibile scrivere il proprio intercettore per memorizzare nella cache i risultati per i livelli sotto il livello dell'interfaccia utente.
• Gestione errore WCF. Non è possibile Dispose un client WCF se è nello stato Faulted, quindi ogni metodo che crea e distrugge un'istanza del client deve controllare lo stato, quindi chiamare Abort se necessario invece di semplicemente racchiudere una clausola using attorno al client. Un intercettore potrebbe non essere la soluzione migliore in questo caso. Probabilmente è più semplice to just fix the Dispose implementation or use some kind of wrapper.

Se gli esempi di cui sopra potrebbero essere buoni candidati per gli intercettori dipende dalle intricate complessità della vostra applicazione. Questo elenco di corso non è esaustivo, né può essere. Le possibili applicazioni degli intercettori sono tanto varie quanto le applicazioni che scrivi.

Come utilizzare intercettori

mi vengono in mente tre luoghi principali in cui si potrebbe applicare un intercettore: Controller, servizi e oggetti di dominio.

• Con un controller MVC, rende più senso di andare avanti e usare MVC's filters.
• Per un servizio di livello intermedio che si sarebbe tirare fuori il vostro contenitore CIO, i filtri non sono un'opzione (perché non è un controller), quindi si dovrebbe utilizzare il interception features of your IoC container.
• Per gli oggetti del dominio che di solito istanzia direttamente con un costruttore (se si tratta di una nuova entità) o recupera dal tuo ORM di scelta (se si tratta di un'entità esistente), è necessario utilizzare una sorta di oggetto fabbrica invece del costruttore e instruct your ORM how to use the factory.

I dettagli nitidi su come eseguire tutto questo dipenderanno dagli strumenti che si stanno utilizzando.