evitando più chiamate a SQL pur essendo modulare

Question

evitando più chiamate a SQL pur essendo modulare

#1 da (7 voti)

6

Ho un BusinessLayer.dll che chiama DataAccessLayer.dll che alla fine rende la connessione TCP al server SQL. Ogni metodo del livello aziendale ha un metodo corrispondente nel livello di accesso ai dati che quindi chiama la rispettiva vista nel database.

Ora la domanda è: cosa devo fare se ho bisogno di ottenere i dati da tre viste contemporaneamente per un metodo del livello aziendale? Queste viste saranno richieste individualmente anche in altre aree dell'applicazione, ma in una o due aree i dati dovranno essere recuperati da tutte e tre le viste contemporaneamente.

Opzione 1: Devo chiamare quei singoli metodi nel livello aziendale in un quarto metodo facendo tre diversi accessi al database tramite i rispettivi livelli di accesso business e dati e quindi raggruppare i dati insieme nel mio livello aziendale o

Opzione 2: dovrei avere solo una procedura memorizzata che chiama queste tre viste e restituire i dati a DataAccessLayer e poi tornare al livello aziendale?

Nell'immagine sopra, l'opzione 1 è indicata dai riquadri verdi e il quarto metodo aziendale è indicato dalla casella nera che avvia i tre colpi alla casella SQL per ottenere i dati.

L'opzione 2 è indicata dalle caselle arancioni. Il vantaggio dell'approccio usando l'opzione 2 è che non si verificano più I / O in rete, ma il codice nel livello dati probabilmente duplica il codice scritto nelle caselle verdi.

Il client può essere un'applicazione Web o Windows. In un'applicazione basata su Windows, il livello aziendale sarà avvolto da un servizio che il client Windows chiamerà. Come si ottiene un equilibrio tra modularità e prestazioni qui?

design c# architecture performance

posta user20358 12.10.2014 - 18:28

fonte

1 risposta

Leggi altre domande sui tag design c# architecture performance

Uso del pattern Decoratore per aggiungere metodi pubblici a un oggetto Devi rinominare il software quando forzi un repo?

score 7 · Answer 1

Nell'ordine:

C'è qualcosa che ti consente di affermare che l'applicazione è lenta? Esiste un requisito non funzionale relativo alle prestazioni che l'applicazione non soddisfa più? sembra lento (nel qual caso la tua prima preoccupazione dovrebbe essere quella di scrivere un requisito non funzionale che indicherà esplicitamente cosa ti aspetti)?

Se l'applicazione è abbastanza veloce, stai facendo un'ottimizzazione prematura. Per favore, non farlo.
Quali sono i risultati quando profili l'applicazione ? L'hai profilata e hai identificato che il fatto che stai facendo tre query invece di una è il collo di bottiglia che influenza le prestazioni in modo molto evidente?

In caso contrario, prima fai questo. Esegui il profiling, identifica i colli di bottiglia. Molto probabilmente, scoprirai che il numero di query (3 vs 1) è la tua preoccupazione minore in termini di prestazioni.

Tieni presente che pool di connessioni (se utilizzi Microsoft SQL Server) riduce notevolmente il costo della chiusura e della riapertura di una connessione diverse volte. Assicurati di chiudere correttamente le connessioni, ad esempio disponi le risorse. Dovresti avere using () { } attorno a tutti SqlConnection s, SqlTransaction s, SqlCommand s, ecc. Lo strumento di controllo statico chiamato Analisi del codice ti aiuta a trovare le cose non correttamente disposte.

Ricorda di profilare le tue visualizzazioni . I piani di esecuzione sono particolarmente utili in questo caso. Guarda gli indici (non necessariamente la mancanza di essi, ma anche quali sono lì e perché). Guarda i dati che carichi e i dati di cui hai effettivamente bisogno (a volte gli sviluppatori caricano troppi dati da un database e poi filtrano a livello di applicazione, sfortunatamente, dato che i database fanno il lavoro di filtraggio molto bene se stessi).

Se stai utilizzando un ORM, osserva le query che crea (potresti utilizzare SQL Server Profiler per questo, la maggior parte degli ORM consente anche di registrare le query che inviano al database). A volte, gli ORM hanno bisogno di aiuto per capire il modo migliore per creare una query ottimizzata.
Utilizzi memorizzazione nella cache ?

Altrimenti, potresti concentrarti su questo prima, prima di affrontare più query rispetto a una query. Dato che stai parlando di visualizzazioni, immagino che non stai modificando i dati, ma solo leggendolo (anche se puoi modificare i dati attraverso le visualizzazioni in Microsoft SQL Server). Ciò significa che questi dati possono molto probabilmente essere memorizzati nella cache sul server, il che significa che invece di 3 o 1 query, avrai 0.

Solo allora, cioè solo se sai che l'applicazione non risponde a un requisito di prestazione non funzionale, che è lento perché fa tre query invece di una e che la memorizzazione nella cache non sarà di aiuto in caso di dubbi per ottimizzazione consistente nel sostituire tre query per uno.

Ricorda che non sei necessariamente costretto a farlo attraverso una stored procedure. Nel tuo caso particolare, poiché tutto ciò che fai è accedere a tre visualizzazioni, creare una quarta vista può essere la soluzione.

In tutti i casi, sono sorpreso che tu abbia riscontrato che le prestazioni (o che tu credi) siano influenzate a livello di I / O da tre query invece di una:

Quale potrebbe essere stato il problema è chiudere e riaprire le connessioni due volte. Come ho detto in precedenza, il pooling delle connessioni risolve il problema.
In generale, il tempo impiegato per inviare una query a un server SQL è quasi zero rispetto al tempo impiegato per la lettura dei dati, a meno che non si stia effettuando una query su un valore scalare.
In generale, il tempo impiegato per inviare una query a un server SQL non è importante quanto il tempo impiegato dal server SQL per caricare i dati (dato che la maggior parte dei server SQL svolge un ottimo lavoro di memorizzazione nella cache dei dati in memoria, che rende la maggior parte delle query estremamente veloce).