È necessario un parere sulla selezione di un metodo di accesso ai dati

Question

Sono nelle fasi iniziali della pianificazione di una conversione di una classica applicazione di database ASP su ASP.Net e ho difficoltà a individuare il metodo di accesso ai dati da utilizzare. Ho giocato con Linq To SQL, Dynamic Data, dataset fortemente tipizzati, Enterprise Library (Data Access Application Blocks) e un pochino con Entity Framework, ma nessuno di loro mi è saltato addosso come "l'unico". Ci sono troppe scelte - la mia testa sta nuotando, aiutami a scegliere!

Forse sarebbe utile dare qualche informazione sulla domanda che sto convertendo con le priorità ...

• il back-end di Microsoft SQL Server (2005 o successivo) e ci siamo impegnati a così, quindi non devo preoccuparmi di supportare mai una piattaforma di database diversa.

• Il database è molto maturo e contiene una grande quantità di logica aziendale. È altamente normalizzato e fa ampio uso di stored procedure, trigger e visualizzazioni. Preferirei non reinventare due ruote contemporaneamente, quindi mi piacerebbe apportare il minor numero possibile di modifiche al database. Quindi, ho bisogno di scegliere un metodo di accesso ai dati che sia abbastanza flessibile da permettermi di aggirare eventuali stranezze nel database.

• L'applicazione ha molti moduli per l'inserimento dei dati e ampie capacità di ricerca e reporting (i report sono un'altra bestia che affronterò in seguito).

• L'applicazione deve essere abbastanza flessibile per gestire modifiche minori alla struttura del database. L'applicazione (e il database) possono essere installati in diversi siti in cui vengono apportate modifiche personalizzate minori al database. Idealmente l'applicazione potrebbe identificare le estensioni del database e reagire in modo appropriato. In altre parole, se ho bisogno di memorizzare una mappatura O/R nell'applicazione, devo essere in grado di sostituirla (o aggiornarla facilmente) durante l'installazione dell'applicazione e del database in un nuovo sito.

• Lo sviluppo rapido delle applicazioni è fondamentale. Dal momento che il database è già stato eseguito e l'interfaccia utente sta andando a corrispondere strettamente all'applicazione esistente, spero di trovare qualcosa in cui possiamo farlo funzionare abbastanza rapidamente. Sono disposto a sacrificare non usando l'ultima e la più grande tecnologia se si risparmia tempo nello sviluppo. In altre parole, se c'è una curva di apprendimento ripida nell'usare qualcosa come Entity Framework, sto andando bene con qualcosa come Dataset fortemente tipizzati e un DAL personalizzato se questo accelera il processo.

• Sono un novizio totale di ASP.Net ma sono intimamente familiare con ASP classico, T-SQL e il vecchio ADO (ad esempio recordset disconnessi). Se qualcuno dei metodi di accesso ai dati è più adatto per qualcuno che viene dal mio passato, potrei orientarmi in quella direzione.

Grazie per qualsiasi consiglio che puoi offrire!

Answer 1

nLa ibernazione potrebbe essere una buona idea. È possibile memorizzare la mappatura in file di configurazione esterni che potrebbero risolvere le vostre esigenze. Un'altra opzione potrebbe essere l'utilizzo di ActiveRecord, che si basa su nHibernate.

nHibernate dispone di una funzionalità utile che potrebbe risultare utile. Si chiama una proprietà Dynamic che è fondamentalmente una collezione di coppie valore nome popolata tirando i nomi delle colonne dal file di mappatura. Quindi quando aggiungi una colonna sul tuo sito cliente, aggiorni il file di mappatura e sarai in grado di accedere ai dati attraverso una collezione sull'oggetto.

Answer 2

Guarda tutte le tre articoli di questa serie:

High Performance Data Access Layer Architecture Part 1

Ottimi consigli.

Answer 3

Si potrebbe voler risolvere il disaccoppiamento del livello database dal livello asp in modo che non solo si possa dare una maggiore flessibilità nel prendere la decisione, ma quando è necessario apportare modifiche al database di un cliente, è sufficiente passare a un nuovo dll senza cambiare altro.

Utilizzando dependency injection è possibile utilizzare xml per indicare al framework quale classe concreta utilizzare per un'interfaccia.

Il vantaggio consiste nel fatto che è possibile procedere con un approccio al database e, se in un secondo momento si decide di passare a un altro, è sufficiente modificare la DLL e procedere senza apportare modifiche ad altri livelli.

Dato che ci si conosce meglio perché non accedere direttamente al database al momento creando le proprie connessioni? Quindi puoi spostare il resto del codice e lungo il tuo percorso puoi decidere quale tra le tante tecnologie da utilizzare.

Per una nuova applicazione su cui sto lavorando Sto iniziando da LINQ a SQL, principalmente perché lo sviluppo sarà più veloce, ma, più tardi, se deciderò che non soddisferà i miei bisogni, lo cambierò.