Quali fattori dovrebbero influenzare il livello di accesso ai dati che utilizzo su un nuovo progetto?

Question

Insegnerò a un sson di classe e devo spiegare quali fattori dovrebbero influenzare la tua decisione in merito alla tecnologia di accesso ai dati. Ho familiarità con molti metodi di accesso ai dati come insiemi di dati tipizzati, Linq to SQL, Linq to Entities, .netTiers, LLBLGen e chiamate personalizzate con oggetti connessione SQL e oggetti comando. Alcuni dei miei clienti consentiranno solo di utilizzare le stored procedure e NON discuteranno di nient'altro. Alcuni dei miei clienti NON sono ancora pronti per installare .NET 3.5. Alcuni client richiedono un livello di servizio Web intermedio in qualsiasi applicazione Web. Il più delle volte utilizzo i set di dati di tipi e i servizi Web personalizzati, oppure utilizzo .netTiers con CodeSmith. A cos'altro dovrei pensare?

Answer 1

Come per tutte le scelte in un progetto software: dipende ... Ma secondo me il fattore più importante è l'ambiente del progetto.

Questo consiste in (non pretendo che questo elenco sia completo in ogni caso):

• Competenze disponibili all'interno del team di sviluppo E del team di manutenzione (se diverso)
• Funzionalità richieste
• Vincoli stabiliti dai client (non tutti i client supportano tutte le tecnologie disponibili. Questo sicuramente qualcosa che dovresti prendere in considerazione quando si sostituisce in modo incrementale un sistema legacy o si introduce un nuovo sistema in un ambiente)
• Vincoli stabiliti dalla legislazione

spero che questo ti aiuti.

Answer 2

Una cosa importante da ricordare è che un database non è necessariamente solo un archivio di dati di supporto per un'applicazione (in isolamento). Altre applicazioni e processi potrebbero eventualmente richiedere l'accesso al database, in particolare in grandi aziende o # 8221; database (o applicazioni) e in particolare con abbastanza tempo.

È importante considerare:

ETL / Carichi / migrazione

Integrazione / sincronizzazione esterne (BizTalk / SSIS)

Riutilizzo da parte di altre applicazioni (in particolare siti Web, applicazioni mobili ecc.)

Superficie di sicurezza / attacco (un approccio è meno sicuro di un altro?)

Attività di manutenzione

Disponibilità: il database sarà in uso 24/7? Un approccio offre una migliore disponibilità rispetto a un altro, ecc.

Inoltre, alcune considerazioni sul design sono in ordine. Stai sintonizzando per selezioni più veloci o scritture più veloci? Un progetto di accesso ai dati potrebbe funzionare meglio di un altro.

Non sto affermando che esiste un solo proiettile d'argento, ma ciò che faccio attenzione è che qualsiasi modello di progettazione di accesso ai dati richiede & # 8220; quadro generale & # 8221; pensato - affronterà le preoccupazioni di oggi e ciò che puoi ragionevolmente prevedere potrebbero essere le esigenze di domani?

Inoltre, fornirai un'API esterna o un framework per un accesso coerente ai dati? Sarà esposto direttamente o indirettamente?

C'è un posto, credo, sia per Entity Framework / LINQ to SQL, sia per le stored procedure tradizionali e altri strumenti come NHibernate (ecc.), ma dovresti prima giustificare e razionalizzare la scelta della tecnologia e provare a assicurarsi che sia appropriato per le esigenze presenti e future.

EDIT: mi dispiace, ho dimenticato quello grande: manutenibilità. Alcune delle soluzioni basate su template offrono alcune vittorie decenti nel riuscire a rigenerare un DAL dopo le modifiche dello schema, rispetto ad altre (come le procedure memorizzate scritte a mano). Vale la pena soppesare gli aumenti di produttività rispetto agli svantaggi.

Answer 3

Penso che tra il tuo post originale e le aggiunte di norbertB hai trattato praticamente di tutto. Inizia con i vincoli assoluti (e ricorda che solo perché un cliente dice no a qualcosa una volta - anche se dicono che è assoluto - ciò non significa che non puoi fare a meno di cambiare idea ...). Dopo aver ristretto il campo con i vincoli assoluti, guarda le altre cose.

Una cosa che sembrava essere stata esclusa era la flessibilità. Ad esempio, se stavo provando a scegliere tra due tecnologie simili e sapessi che uno poteva supportare visualizzazioni aggiornabili e l'altro no, anche se al momento non avevo assolutamente bisogno di visualizzazioni aggiornabili, mi spingerei ancora verso quella " ; nel caso in cui " ;.

Answer 4

Sto davvero pensando solo a due cose. Il primo è se avrò così tanti dati che qualsiasi altra cosa conta. Se non stai inserendo milioni di righe nelle tabelle, probabilmente non importa quale tecnologia utilizzerai perché funzioneranno abbastanza velocemente.

La seconda cosa è se posso usare LINQ, perché trovo che usare LINQ (su SQL, su Entità, su LLBLGen, non importa) per interrogare il database ti dà due cose importanti. Il primo è che è molto semplice scrivere query e in secondo luogo, è moderatamente facile passare tra due framework che richiedono LINQ, nel caso in cui i requisiti cambino.