Quale strategia di accesso ai dati per un'applicazione di grandi dimensioni

Question

Sto per iniziare una riscrittura di un'applicazione VB6 in .NET 3.5sp1. L'app VB6 è abbastanza ben scritta e il livello dati è completamente basato su procedure memorizzate. Vorrei andare con qualcosa di automatizzato come Linq2SQL / Entity Framework / NHibernate / SubSonic. Devo ammettere che non ho usato nessuno di questi strumenti in progetti diversi da quelli usa e getta.

Il potenziale problema che temo di avere con tutte queste scelte è la velocità. Ad esempio, in questo momento per recuperare una singola riga (o l'intero elenco), utilizzo il seguente sproc:

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL
AS

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name

Per recuperare una singola riga in Linq2SQL / Entity Framework / NHibernate / SubSonic, queste soluzioni dovrebbero portare l'intero elenco al client e trovare la riga di cui ho bisogno?

Quindi, qual è il consenso per la strategia di accesso ai dati per un'applicazione con un dominio di dati di grandi dimensioni?

Answer 1

Farò il ruolo del difensore del diavolo e ti consiglio almeno di considerare di seguire le procedure memorizzate. Questi rappresentano un pezzo di codice che non è necessario riscrivere ed eseguire il debug. Questo articolo del nostro proprietario [tm] Joel Spolsky fornisce un argomento coerente per evitando riscritture complete.

Dato un progetto 'greenfield' puoi usare quello che vuoi, e un mapper O / R potrebbe essere una buona scelta. Tuttavia, hai già dichiarato che l'app VB6 è ben scritta. Se gli sprocs sono ben scritti, allora ottieni alcune delle tue app gratuitamente e viene già eseguito il debug, oltre a riciclare lo schema del database ed evitare la maggior parte del dolore derivante dalla migrazione dei dati.

Patterns of Enterprise Application Architecture di Fowler dovrebbe darti alcuni buoni suggerimenti per progettare un livello di accesso ai dati che giocherà perfettamente con le procedure memorizzate senza causare problemi di manutenzione.

Questo viene fatto abbastanza comunemente su app Oracle / Java. Molte app Oracle legacy dispongono di grandi quantità di codice di procedura memorizzata in PL / SQL: questa era un'architettura standard ai tempi client-server di Oracle Forms. È pratica comune scrivere un wrapper per gli sprocs in Java e creare l'interfaccia utente sopra il wrapper.

Uno degli altri poster menzionava che Subsonic può generare involucri per gli sprocs.

Una volta ho avuto occasione di fare un hack del dizionario dei dati che ha generato un wrapper Java / JDBC di prova per sprocs PL / SQL - IIRC ci è voluto solo un giorno circa. Dato che non è così difficile da fare, sarei sorpreso di scoprire che non c'è molta scelta nelle cose che puoi ottenere dallo scaffale per farlo. In un pizzico, anche scrivere il tuo non è poi così difficile.

Answer 2

Non posso parlare su Linq-to-SQL, Entity Framework o NHibernate, ma sono innamorato di SubSonic. La mia esperienza con essa è stata straordinariamente positiva.

Il modo in cui funzionano questi strumenti, in generale, è che creano query con parametri per te nel codice gestito, incapsulano tale accesso nelle classi, quindi espongono quelle classi alle tue app. Rock DALs completamente generato.

Utilizzando le query con parametri, la tua preoccupazione che potrebbero "quotare l'intero elenco verso il cliente e trovare la riga di cui ho bisogno" è gestito. Supportano le clausole where e altri filtri per ottenere solo le righe necessarie. Puoi fare l'equivalente di select * da foo , ma non sei bloccato in quella modalità.

Detto questo, SubSonic - se usato fuori dagli schemi per l'accesso diretto alla tabella / vista - abbassa intere righe, che potrebbe essere un aspetto negativo in alcuni scenari. Tuttavia, l'accesso tramite proc memorizzati non è un problema: non posso parlare con gli altri, ma SubSonic crea utilmente una classe SPs che incapsula tutti i tuoi proc, permettendoti di chiamarli come metodi e restituendo i DataTable appropriati, che è quindi possibile analizzare manualmente in base alle esigenze. Esistono anche modi per inizializzare elenchi di classi DAL da procs, quindi se proc restituisce un set di dati che corrisponde direttamente a una tabella / vista, è comunque possibile avere la sintassi più pulita senza elaborazione manuale.

(SubSonic, a proposito, mi ha curato di "procs per tutto". Ora, in genere, non passo quasi mai tempo a fare proc di CRUD come facevo in passato, e finisco per usarli solo per rapporti complicati. Ma il tuo chilometraggio può, e in effetti può variare.)

Answer 3

Consiglierei di usare SubSonic per generare tutto il codice per accedere ai tuoi processi memorizzati esistenti, in questo modo riduci le possibilità di regressione a causa di un nuovo livello di accesso ai dati. È possibile accedere a qualsiasi nuova funzionalità tramite le classi ActiveRecord generate da SubSonic. Questo mi sembra essere l'approccio più sicuro e veloce per procedere,

Non sono d'accordo con la raccomandazione NHibernate perché non è molto adatto per lavorare con le stored procedure.

Answer 4

Abbiamo provato a utilizzare il framework di entità come un ORM e abbiamo riscontrato diversi problemi durante il tentativo di utilizzarlo con Domain Driven Development. Linq to Sql ha anche alcune limitazioni e credo che Microsoft smetterà di supportarlo nella prossima versione, credo.

Answer 5

Se le query si trovano in stored procedure, è molto probabile che siano già state ottimizzate. E probabilmente usano liberalmente le espressioni SQL per JOINS, sottoquery, ecc.

Duplicare quel tipo di efficienza ed espressività, accuratamente , con uno strato di astrazione di tipo ORM, mi aspetterei che sia una sfida, specialmente se non hai familiarità con gli strumenti.

Puoi sempre rielaborare le query dopo aver ottenuto il resto dell'app direttamente. E il mondo ORM sta cambiando abbastanza velocemente che le opzioni saranno sicuramente diverse quando ci arriverai.

Answer 6

SubSonic, anche secondo Rob Connery, uno degli autori, è scritto più per supportare lo sviluppo rapido di applicazioni e meno per applicazioni di grandi dimensioni. Direi di andare con NHibernate poiché troverai il maggior supporto dalla community e un framework collaudato. Puoi ottenere buone informazioni da www.dimecasts.net sull'impostazione dei tuoi contenuti NHibernate.