Guida all'architettura del livello dati

Question

Guida all'architettura del livello dati

#1 da (2 voti)

4

Ho bisogno di aiuto per progettare un livello di accesso ai dati usando Entity Framework. Ecco i requisiti:

Il database è preesistente, un disordine assoluto, ed è struttura e non può essere modificato
verrà utilizzato Entity Framework
Il database verrà utilizzato da dozzine di applicazioni .NET MVC ciascuna con il proprio set di oggetti business, logica e autorizzazioni di lettura / scrittura.
Gli oggetti dati richiesti da queste applicazioni di solito hanno poca somiglianza con le tabelle memorizzate nel database.
Il livello di accesso ai dati deve essere il più semplice possibile da usare per gli sviluppatori che lo utilizzano.

Non ho mai lavorato su nulla di questo ambito prima e apprezzerei qualsiasi aiuto su come progettare questa soluzione. Quello che ho finora è:

Progetto 1: DataLayer

• contiene un modello di dati puramente EF generato

Progetto 2: BusinessLayer

• contiene la logica per convertire oggetti dal DataLayer in oggetti di business utilizzati dalle viste e viceversa. La maggior parte (ma non tutte) la logica è condivisa tra le applicazioni. • Contiene oggetti DTO / business comuni utilizzati da tutte o più applicazioni

Progetto 3: ServiceLayer.Application1

• contiene tutti gli oggetti DTO / business per l'applicazione 1 • contiene un repository che deve essere utilizzato dall'applicazione 1

Progetto 4: ServiceLayer.Application2

• contiene tutti gli oggetti DTO / business per l'applicazione 2 • contiene un repository che deve essere utilizzato dall'applicazione 2

Pronunciare un'applicazione MVC utilizzando il livello dati necessario per ottenere un IQueryable e l'oggetto business FacultyFormattedForAView è composto da dati provenienti da 6 diverse tabelle con una logica aziendale generata in alto. Ecco come immagino le cose andando:

L'applicazione crea un'istanza del rispettivo repository nel livello di servizio e chiama IQueryable GetAllFacultyFormattedForAView ().
Il livello di servizio effettua una chiamata al livello aziendale: IQueryable GetAllFaculty (). L'oggetto business Facoltà è costituito da dati di 4 diverse tabelle.
Il livello aziendale restituisce un'istruzione LINQ che converte gli oggetti delle classi EF generate che vivono nel livello dati in una Facoltà
Il livello di servizio converte gli oggetti Faculty in oggetti FacultyFormattedForAView e restituisce il risultato all'interfaccia utente

Utilizzando questa struttura, la tavolozza comune di comandi esisterebbe nel livello aziendale per evitare qualsiasi duplicazione del codice e il repository esporrà solo i comandi a cui ha accesso una determinata applicazione e fornirà una formattazione aggiuntiva specifica per tale applicazione.

Sto usando IQueryable piuttosto che IEnumerable in modo che sia possibile utilizzare il paging e l'ordinamento. Vedendo come sto solo esponendo gli oggetti business / DTO agli sviluppatori, ho pensato che fosse ok, anche se mi piacerebbe che non dovessero fare una ToList () o altro per poter effettivamente eseguire la query.

Questo è il meglio che ho potuto inventare, ma non posso scuotere la sensazione che potrei fare qualcosa di meglio.

Apprezzerei qualsiasi feedback.

Grazie.

architecture entity-framework

posta Ben 03.05.2016 - 20:39

fonte

1 risposta

Leggi altre domande sui tag architecture entity-framework

Iniezione di dipendenza e istanziazione in classe | Limiti pratici Ricerca di liste tuple uniche di opzioni

score 2 · Answer 1

Per la parte "Messy DBs" triste mi raccomando

un libro di Scott Ambler "Database Refactoring", ti insegna molto sul mondo reale dei database, e no, sicuramente non ti salverà da SQL, ma potrebbe salvare la vita del tuo prodotto, cioè portarlo a stato mantenibile.
non temere l'SQL, masterizzarlo (TSQ, PL / SQL e altri linguaggi DB nativi)

E EF, alcuni punti della mia esperienza

EF è adatto per progetti greenfield in cui è previsto un problema di associazione tra i dati in DB e le istanze dell'oggetto .NET
non utilizzare SQL se stai creando un PoC o una demo o un'applicazione che non sembra scalare in dimensioni, complessità e velocità di elaborazione
non dovresti limitarti a non usare SQL se vuoi creare un'applicazione mantenibile (in termini di prestazioni) - ci sono buone ragioni per i bit di SQL, almeno nelle parti altamente dipendenti dal rendimento
Ho visto le soluzioni EF di EF ben più grandi con un numero maggiore di DB (miliardi di righe di tabelle di lettura-scrittura, in produzione fino a milioni di utenti) e no, non è possibile eliminare SQL se "davvero" Significa ".

Il mio consiglio per la parte EF:

assumi un vero guru SQL hands-on-operations che in realtà è un programmatore e conosce gli ORM, quindi non tenderà a rendere SQL un Gold Hammer, né a prendere le decisioni EF / SQL su di lui. Ho incontrato alcune di quelle persone e, purtroppo per la maggior parte della mia carriera, ho dovuto fornire questo ruolo in vari progetti, e non posso immaginare come sarebbero finiti i progetti senza questo tipo di esperienza disponibile.