Separazione di dubbi, livello di accesso ai dati

Naviga le tue risposte
2

stavo pensando a questo prima oggi e ho pensato di ottenere un input sulla questione. Quando sviluppo applicazioni, in genere avrei il livello di accesso ai dati su un altro progetto, nel caso in cui potrebbe essere riutilizzato altrove in un modo simile in futuro, ma anche per consentire l'aggiornamento del DAL senza aggiornare il livello dell'interfaccia utente.

Nel fare ciò gestisco tutte le query di dati ecc. nel DAL. L'applicazione non ha bisogno di sapere se è ADO.NET, EF o una lista. Tuttavia, mi è venuto in mente che in quasi tutti i casi i tipi di ritorno sono specificati nel DAL. Quindi il livello dell'interfaccia utente deve conoscere i tipi definiti lì. È normale o esiste un modo per una maggiore separazione? (oltre a usare i tipi Anon)

    
posta James 11.06.2013 - 18:02
fonte

2 risposte

2

Il disaccoppiamento completo non è realistico; alla fine si finisce con un goo grigio (dati amorfi senza forma). I dati senza forma sono dati senza significato.

I tipi di dati sono già specificati più o meno implicitamente, a causa della forma dei dati, e EF già astrae l'archivio dati sottostante (anche se in pratica raramente conta comunque, cambiare il fornitore del database una volta scelto è estremamente raro), così un'ulteriore astrazione potrebbe essere una questione di rendimenti decrescenti.

Tutto ciò detto, se hai davvero bisogno di un'ulteriore astrazione, lo fai nel solito modo: creando un altro livello software, come un repository (che non hai ancora menzionato). Oppure, puoi abbandonare tutto ciò, adottare l'approccio minimalista e utilizzare solo un negozio Key / Value come BigTable.

Vedi anche
Perché è una buona idea per i livelli di applicazione "inferiori" non essere a conoscenza di quelli "più alti"?

    
risposta data 11.06.2013 - 20:00
fonte
1

Sì. Questo è un problema comune con molte soluzioni DAL. Questo è il motivo per cui le persone hanno iniziato a usare POCO / POJO. Questo ti permette di definire entità / oggetti in un progetto. Quindi, definire i mapping dei database in diversi progetti, che fanno riferimento a tali entità.

Le prime versioni di EF non lo consentivano. Solo le ultime versioni. NHIbernated (e altri ORM di terze parti) consentono questo diritto fin dalle prime versioni. Puoi anche creare repository e implementazioni da solo. Ma scoraggerebbe la creazione di una tua se già usi una soluzione ORM, perché diventerebbe ridondante.

Ma ci sono ancora molti problemi legati a questa separazione. Anche con POCO / POJO, le perdite di accesso ai dati nelle entità di base. Il più comune è la necessità di rendere le cose pubbliche / protette anche se dovrebbero essere private.

    
risposta data 11.06.2013 - 20:02
fonte

Leggi altre domande sui tag

.c Interfaccia dedicata ai dati Che cosa dovrebbe contenere una corretta definizione Ready for Sprint?