Ci saranno quelli che sono in disaccordo con me (DBA hi!) Ma ORM totalmente rock. Oggetto Mappers relazionali sono stati intorno per un po 'di tempo e si può li riconoscerete dai nomi come LINQ to SQL, NHibernate e Entity Framework (tra gli altri). L'idea di ORM è che tutto l'impianto idraulico tra le entità in app e le entità del database può essere astratto in un quadro che sono gestite in modo che l'accesso ai dati può diventare un non sporca, senza fronzoli affare.
Come in molti modi automatici per costruire applicazioni, ORM hanno le loro insidie e uno dei peggiori - e più comune - è il temuto "n +1" causata da lazy loading. Ecco come una condizione di n +1 si manifesta:
- È interrogare il database e tornare un po 'di record in una tabella (questa è una query)
- Nel codice applicazione, di leggere ogni record e si riferiscono a uno o più attributi che devono essere tirato da altre tabelle
- Ogni record provoca poi l'applicazione per andare fuori e fare un mucchio di altre query, al fine di recuperare gli attributi del punto precedente (il bit n)
Il bit lazy loading avviene a seguito di quella prima query restituisce solo l'entità e non tutti gli altri attributi per cui deve tornare per il terzo punto (scansafatiche). Pensate a come questo, prendiamo questa query:
SELEZIONA * FROM dbo . Prodotti
Ora l'immagine che ogni prodotto ha una categoria che viene normalizzato su un altro tavolo e si desidera visualizzare questo per gli utenti che significa che per ogni record si finisce per fare questo:
SELEZIONA * FROM dbo . Categorie WHERE IDCategoria = 1
SELEZIONA * FROM dbo . Categorie WHERE IDCategoria = 2
SELEZIONA * FROM dbo . Categorie WHERE IDCategoria = 3
E così via e così via. Questo accade facilmente, perché ORM sono così semplici da implementare e interrogare senza realmente vedere ciò che sta succedendo al di sotto in SQL Server. Ho visto casi in cui una singola pagina con 20 registrazioni su di esso stava facendo 2000 - sì, 2000 - query al DB. Lo sviluppatore non lo sapevo perché ancora una buona performance nei confronti di un piccolo insieme di dati in un DB locale con un singolo utente, ma modificare una qualsiasi di queste condizioni e le cose stanno andando ottenere molto brutto molto rapidamente.
Il problema è identificare un n +1 condizione in primo luogo, e c'è un certo numero di approcci a questo. L'altro giorno ho inviato alcuni suggerimenti di prestazioni rispetto alla Porta Rossa, che dove poi incluso nel loro libero (sì - gratis!) EBook dal titolo 50 modi per evitare, Individuazione e correzione di problemi di prestazioni ASP.NET . La punta di cui sto parlando qui è questa:
Sempre profilo vostri colpi di database con SQL Profiler ORM durante lo sviluppo. ORM scappare da te molto rapidamente. Prima che tu lo sai, hai eseguito una query di 2000 volte in un ciclo, quando si potrebbe avere recuperato tutti i dati con un colpo singolo database.
SQL Profiler è un modo di fare questo, ma un altro strumento che fa anche un grande lavoro di mettere in evidenza i vostri risultati del database èPrestazioni ANTS Profiler . In ANTS infatti fa un mucchio di altre cose molto utili che ottiene a destra sotto le coperte del vostro. App NET e le prestazioni dei profili fino a un livello di grana molto fine e lo rende morto semplice (un classico Red Gate Software tratto). Così semplice, infatti, che ho pensato che valeva la pena di aggiungere alla mia serie di cinque minuti si chiede perché vale la pena di un video (un video molto veloce), per dimostrare come funziona correttamente:
Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso asp.net
Corso C# - Corso PHP - Corso Joomla
