dove dovrebbero risiedere i set di dati in un'architettura di livello n (a più livelli)?

Question

Al momento stiamo discutendo se il set di dati dovrebbe andare nel livello dati o aziendale?

Il mio amico pensa che tutti i componenti ADO.NET dovrebbero andare nel livello dati. Per me questo non sembra giusto per i seguenti motivi:

• Se crei un client Data Layer scadente, sarà molto più difficile, ad esempio, migrare tutto su una diversa origine dati.
• Non puoi avere controlli associati a meno che non salti la logica del livello aziendale.

Penso che i set di dati e i database siano nella logica aziendale poiché sono generici per tutti i fornitori di dati. Il livello dati dovrebbe avere una Provider Factory per creare un'istanza degli oggetti del provider giusto (Connection, DataAdapters, Transactions, DataReaders, ecc.). Per me questo è il modo di procedere per i seguenti motivi:

• La migrazione a un diverso livello dati è semplice come si arriva.
• Puoi associare i tuoi controlli a ricchi oggetti business

Qualche guru di livello N può aiutarci a chiarire quale strada fare? Grazie in anticipo

Answer 1

Dove sono, restituiamo set di dati, database, datarows e datareader dal livello dati al livello aziendale.

La logica è che questi tipi non sono specifici di db-flavour. Sia che usi mysql, access, sql server, oracle o qualunque sia un set di dati che sia un set di dati, e quindi va bene tornare da un livello dati a livello di radice.

Un livello aziendale prende quindi questi dati grezzi e li trasforma in oggetti business fortemente tipizzati & # 8212; applicare le regole commerciali necessarie & # 8212; per passare al livello di presentazione.

---

Modifica: mentre guardo un po 'di codice, non usiamo molto un set di dati completo. Sono principalmente database e datareader.

Answer 2

Secondo me, non usare affatto DataSet. Non usare nemmeno DataSet tipizzato. Questi sono vecchi costrutti creati prima di LINQ. Passa direttamente alla storia antica ed entra nel presente: usa LINQ to Entities e Entity Framework (EF). I due sono strettamente correlati ma non uguali.

Non esporre un'entità EF oltre un limite di servizio. Purtroppo Microsoft ha scelto di esporre i dettagli di implementazione durante la serializzazione di un'entità. Oltre a ciò, usa EF e divertiti molto più di quanto avresti avuto con DataSet.

Answer 3

Beh, isolare l'accesso ai dati non è nuovo: lo facciamo 15 anni fa (sì, 15 anni fa!).

Ho lavorato in molti luoghi e ho visto molti livelli di dati isolati.

Ma non l'ho mai fatto! - visto sostituire un'origine dati!

Sì, l'ho visto due volte: e due volte, sostituiamo anche il livello dati oudated e tutto il software di toping ...

La mia risposta è piuttosto semplice: a meno che tu non stia lavorando per software shelve, puoi isolare quanto vuoi il livello dati, lo farai per niente.

Per niente perché nessuno cambierà SQL Server o Oracle solo per cambiare. E per niente perché il giorno in cui qualcuno lo farà, o riscriveranno anche i loro software o faranno in modo che il prodotto che stanno acquistando sia compatibile con il prodotto che stanno lasciando.

Nei miei libri, ogni livello di dati è stupido.

Se non sei d'accordo, dimmi solo quando nella tua vita questo livello salva $$$ a qualcuno ...

Answer 4

Un approccio tipico è quello di esporre un'interfaccia di repository radice aggregata (come il Cliente) nel livello / dominio della logica aziendale e implementare i repository concreti nel livello / infrastruttura di accesso ai dati.

Answer 5

Il problema fondamentale che ho con i DataSet è che le loro strutture sono un mirror esatto dello schema del database.

Se si espone il DataSet al codice di rendering della pagina effettivo, si sta effettivamente esponendo lo schema del database (il backend finale del prodotto) al livello di presentazione. Ora il problema ovvio può accadere: più avanti lungo la strada vorrai ristrutturare lo schema di dati sottostante e, a causa della progettazione, dovrai applicare le modifiche a tutti gli altri livelli del sistema. È un ottimo esempio di incapsulamento che non viene usato quando dovrebbe essere.

Se si intende utilizzare DataSet, mantenere i DataSet nascosti nel livello di accesso ai dati ed esporre un insieme concettuale di oggetti business al livello di presentazione. L'insieme di oggetti business esposti deve essere progettato in base a principi orientati agli oggetti validi, che è completamente diverso dai principi di progettazione del database relazionale.

Answer 6

Dovrei essere d'accordo sul non usare affatto i DataSet. Una delle applicazioni su cui ho lavorato erano DataSet sia nel livello Dati che nel livello Applicazione. I DataSet DataLayer corrispondevano al DataBase in cui i set di dati del livello Applicazione denormalizzavano le informazioni per renderle più consumabili per il frontend.