.NET Perché dovrei usare DAL per accedere direttamente al database

Sia che si utilizzi un DAL o meno, l'applicazione continuerà a interagire direttamente con il database.

Generalmente è solo una buona pratica strutturare il tuo codice in modo tale che cose come l'accesso ai dati siano in un "luogo" centralizzato nella tua base di codice.

Inoltre, in genere, astraggo qualsiasi accesso ai dati a un insieme di metodi definiti su un'interfaccia .

Se e quando decidi di cambiare il tuo database, non devi setacciare l'intero codice base per tutto il codice di accesso ai dati per aggiornarlo.

Inoltre, utilizzando un'interfaccia approch per astrarre il codice DAL, è possibile scrivere più facilmente unit test per il codice che utilizza l'output DAL.

È semplicemente un buon progetto lavorare in questo modo.

Dovresti usare un DAL, ma non per i motivi indicati :) Probabilmente il problema delle prestazioni non verrà risolto introducendo uno strato di riferimento indiretto (anche se potrebbe essere auspicabile per altri motivi). Si dovrebbe esaminare ciò che effettivamente causa il problema di prestazioni. Alcuni problemi comuni:

• L'antipattern n + 1 che causa molte query sul database. Per esempio. se si preleva un elenco di 100 elementi dal database, questo dovrebbe richiedere una query, ma se si effettua per errore una singola query per ciascun elemento, si ottengono improvvisamente più di 100 query, che interromperanno le prestazioni del database. È possibile rilevare quali query vengono effettivamente eseguite tramite il profiler del database.
• I client conservano troppo a lungo le connessioni db, causando l'esaurimento del pool di connessioni. Per esempio. un SqlConnection aperto viene memorizzato in un campo piuttosto che chiuso immediatamente dopo l'uso.

La struttura .net include già un DAL di basso livello (classi come System.Data.SqlClient.SqlConnection se si utilizza uno SqlServer) che, tra le altre cose, gestisce il pool di connessioni. Questo è piuttosto importante per le prestazioni e non vi è alcun motivo per non utilizzare queste classi per accedere al database.

Immagino che tu già usi questo livello, e tu amico stai facendo un ulteriore livello di riferimento indiretto tra la libreria di accesso ai dati .net e la logica dell'applicazione - forse un ORM come Entity Framework o NHibernate, o un equivalente laminato a mano .

Questo non ti aiuterà con prestazioni, sicurezza o scalabilità. Potrebbe rendere l'applicazione più semplice e più gestibile, ma non risolverà i tuoi problemi immediati.

Modifica: OK, stai parlando di un livello di servizio web. Inoltre, i client di app desktop si connettono a un database centrale su una rete locale. Quindi stai parlando di trasformare un'applicazione a due livelli in un'applicazione a tre livelli. Questo non ti aiuterà con problemi di prestazioni . Piuttosto, peggiorerà ulteriormente a causa dell'overhead di un ulteriore livello. L'introduzione di uno strato di middleware potrebbe tuttavia avere altri vantaggi. Ad esempio, si isolano i client dal database che possono migliorare la sicurezza. Ma se stai andando in quella direzione, potresti prendere in considerazione l'utilizzo di un'applicazione wep, che ha gli stessi vantaggi, ed è molto più facile da implementare e strumentare rispetto alle app desktop.