Vantaggi e svantaggi dell'utilizzo di Enterprise Library

Question

Im appena avviato un progetto e poiché questo progetto è personale mi chiedevo quali sono i vantaggi dell'utilizzo di Enterprise Library? Usiamo la versione 2 per diversi progetti in ufficio, ma non sono abbastanza sicuro (a parte le buone pratiche) dei vantaggi di esso, specialmente nel componente del database. Qualche consiglio? Grazie

Answer 1

Per il blocco di applicazioni di database, il vantaggio principale è che semplifica la produzione di codice agnostico del database. Lo sviluppatore interagisce principalmente con oggetti generici Database e DbCommand, piuttosto che con SqlConnection, SqlCommand, ecc. In questo modo, il passaggio a un altro database (ad esempio Oracle) diventa più fattibile. A seconda delle esigenze di business, questo potrebbe essere un netto vantaggio. EntLib sollecita inoltre lo sviluppatore nella direzione dell'utilizzo di DbParameter per i parametri di query, riducendo il rischio di attacchi di SQL injection.

Come un altro poster menzionato, il blocco delle app di dati è un po 'più alto rispetto alle classi ADO.NET dirette, quindi tende a richiedere meno linee di codice per fare la stessa cosa.

Dal mio punto di vista, i dati, le eccezioni e i blocchi di registrazione sono i più utili. Eccezione e registrazione insieme semplificano la registrazione delle eccezioni (duh) in un numero di punti e in numerosi formati. Ad esempio, possono inserire l'intera voce del registro delle eccezioni, inclusa la traccia dello stack, nel registro eventi di Windows, rendendo relativamente facile la diagnosi di un problema.

Uno svantaggio di EntLib è che alcuni blocchi di app inseriscono un bel po 'di logica nei file di configurazione. Quindi la tua logica è più diffusa; alcuni di essi sono in codice, alcuni nei file di configurazione. Il lato positivo è che la configurazione può essere modificata post-build e persino post-deployment.

Answer 2

Il mio team ha effettuato una valutazione dello Microsoft Patterns and Practices Enterprise Library circa 2 anni fa come parte di una riprogettazione della nostra linea di prodotti. L'unica parte che abbiamo finito per utilizzare era il blocco del database. Abbiamo persino integrato questo in alcune classi che abbiamo potuto creare in modo da poter prendere in giro il DAL per il test delle unità; il blocco di codice Microsoft utilizzava le chiamate statiche per il lavoro del database. Non sono sicuro che Microsoft abbia integrato qualsiasi componente di LINQtoSQL o Entity Framework nel blocco db. Sarei restio a utilizzare il blocco db ora se non ne sfrutta uno.

Per quanto riguarda la registrazione, abbiamo trovato Log4Net una soluzione molto più robusta e flessibile della registrazione Microsoft. Siamo andati con quello per le nostre esigenze di registrazione.

Per la gestione delle eccezioni, abbiamo eseguito il rollover. Il codice Microsoft non gestiva i casi remoti che volevamo gestire e, poiché stavamo usando un framework di registrazione di terze parti, aveva più senso scrivere la nostra libreria delle eccezioni e integrarci con quella. Ho trovato che un certo livello di integrazione del framework di registrazione nel framework delle eccezioni può essere molto utile. Abbiamo scritto alcune classi di wrapper leggere su Log4Net e abbiamo chiamato quelle dalla nostra registrazione delle eccezioni, quindi non abbiamo introdotto dipendenze su Log4Net.

Answer 3

Oltre agli elementi menzionati da Paul sul blocco di applicazioni dati, vorrei anche sottolineare che nella mia esperienza il blocco di applicazioni dati offre anche un modo molto più rapido per scrivere il codice del database necessario, con gli helper esistenti . Lo uso per il suo aspetto coerente e la velocità di sviluppo.