La traduzione dell'entità dovrebbe essere nel livello dati o nel livello aziendale

2

Da quanto ho capito, anche se il livello dati dovrebbe isolare la tecnologia dati dal resto dell'applicazione, anche per me questo include lo schema in questo caso l'entità dati. Recentemente ho visto il progetto Silk di Patterns & Pratica link e ha notato che le entità di dati vengono tradotte nel livello aziendale anziché nel livello dati.

Penso che il vantaggio sia che evita il livello dati per fare riferimento a un assembly che contiene il modello di business. Tuttavia il fatto che esponga pubblicamente entità di dati è a mio avviso uno svantaggio perché i componenti esterni potrebbero dipendere dallo schema dei dati.

Mi piacerebbe capire perché traducono le entità dati nel livello aziendale e quali sono i vantaggi?

So che usano il primo framework di entità del codice, in modo che le entità non abbiano dipendenza correlata alla tecnologia dei dati, tuttavia la responsabilità è ancora quella di strutturare il modello di dati non il modello di business.

Grazie

    
posta Dominik Délisle-Ong 11.02.2014 - 15:17
fonte

2 risposte

1

Immagino che la conversione avvenga nel Business Layer in contrapposizione al Data Layer in modo che il Data Layer non abbia bisogno di conoscere ogni caso del suo utilizzo.

Con l'approccio attuale è responsabilità del codice chiamante sapere come utilizzare il livello dati. Se la conversione è avvenuta nel livello dati, dovrebbe essere a conoscenza di tutti i casi di codice chiamante.

Questo può essere piuttosto semplice in un primo momento, perché probabilmente hai un rapporto 1: 1 tra Business Objects / Entities e lo schema di archiviazione, ma non sarà sempre così.

Prendi l'esempio di due dipartimenti in un'azienda che lavora con un concetto simile ... diciamo un flusso di lavoro di approvazione. Il dipartimento A chiama ogni passaggio del flusso di lavoro a Bla . Il Dipartimento B adora che il Dipartimento A abbia automatizzato il proprio flusso di lavoro e desideri lo stesso, ma chiama i suoi passaggi del flusso di lavoro BongoBlas . È un fatto fondamentale del dominio aziendale che i due flussi di lavoro siano identici e lo saranno sempre, ma il processo aziendale è tale che i passaggi hanno nomi diversi (e anche alcuni dei campi dei metadati hanno nomi diversi).

In questo caso potresti sviluppare una seconda entità aziendale che utilizza la stessa persistenza della prima.

Se il livello dati era responsabile delle conversioni, ora sarebbe necessario estenderlo per gestire le conversioni BongoBla e le conversioni Bla esistenti. Questo sembra un po 'strano perché per quanto riguarda il livello dati questo è nessuna delle sue preoccupazioni .

Il livello dati è indipendente dal consumatore.

Ecco perché è più sensato che i consumatori del livello dati siano responsabili della conversione dei dati. Quando vengono aggiunti nuovi consumatori, deve essere scritto solo il codice del consumatore. Il livello dati può rimanere intatto. E questo ha senso perché le preoccupazioni del Data Layer non sono realmente cambiate.

Nota: ci scusiamo per lo scenario di esempio zoppo sopra. Se penso a qualcosa di meglio aggiornerò la risposta.

    
risposta data 11.02.2014 - 15:55
fonte
0

Non puoi rendere le cose totalmente indipendenti e devi fare le tue scelte. Ma penso che ciò che conta sia avere una traduzione da un lato.

Quale parte potrebbe cambiare più spesso? Scegli questa parte e prova a dipendere da essa il più piccolo possibile.

because external components may be dependent of the data schema

Se il livello dei dati del progetto cambierebbe molto, allora è svantaggioso. Se il livello dati è più stabile, non ci sono problemi.

    
risposta data 11.02.2014 - 15:53
fonte

Leggi altre domande sui tag