modello di repository con un database legacy e Linq to SQL

Question

Sto creando un'applicazione su un database legacy (che non posso cambiare). Sto usando Linq to SQL per l'accesso ai dati, il che significa che ho una classe (Linq to SQL) per ogni tabella.

Il mio modello di dominio non corrisponde al database. Ad esempio, ci sono due tabelle denominate Users e Employees , e quindi ho due classi Linq to SQL denominate User e Employee . Ma nel mio modello di dominio mi piacerebbe avere una classe User che dovrebbe contenere alcuni campi di entrambe le tabelle (ma non mi interessano molti altri campi di queste tabelle).

Non sono sicuro di come dovrei progettare i miei repository:

• i repository devono eseguire il mapping tra le classi Linq to SQL (ad es. User , Employee ) alle classi di dominio ( User ) e solo restituisce le classi di dominio all'applicazione
• o i miei repository dovrebbero restituire le classi Linq a SQL e lasciare il mapping al chiamante

Il primo approccio sembra avere più senso per me, ma è questo il modo corretto di implementare i miei repository?

Answer 1

Il purista (cerco di rimanere puro) ti dirà che il tuo modello rappresenta i tuoi dati. E quindi, tutto ciò che deve essere persistito viene fatto solo quando necessario attraverso i repository. Inoltre, quando si hanno entità complesse, si desidera utilizzare un servizio per combinarle. Ad esempio, Utente + Dipendente = Entità UserEmployee accessibile solo tramite un IUserEmployeeService.

Con quelle dichiarazioni vaghe, hai un'ottima opportunità qui.

Crea un livello anticorruzione, che ti consenta di iniziare a uscire dal DB legacy contemporaneamente.

Questo è un altro capitolo del playbook DDD. Un livello anticorruzione viene utilizzato per interfacciarsi con un sistema legacy mediante facciate, traduttori e adattatori per isolare il DB legacy con il modello di dominio puro.

Ora, potrebbe essere molto più lavoro di quello che volevi. Quindi, devi chiederti a questo punto:

  

Voglio iniziare il processo di   allontanarsi da questo DB legacy o volontà   rimane per la vita del   applicazione?

Se la tua risposta è puoi iniziare a migrare, allora modella il tuo dominio attuale nel modo desiderato. Persistilo con normali repository e servizi. Divertiti a progettarlo nel modo in cui lo desideri. Quindi, usa i servizi delle radici aggregate per raggiungere il livello anticorruzione ed estrarre le entità, archiviarle / aggiornarle localmente e tradurle nelle entità del tuo dominio.

Se la risposta è che il DB legacy rimarrà per la vita del progetto, allora il tuo compito sarà molto più semplice. Utilizza i servizi del tuo dominio (ad esempio UserEmployeeService) per accedere a UserFacade e EmployeeFacade dell'anti-corruzione (simile a un concetto di "Servizio remoto").

All'interno delle facciate, accedi al db legacy usando gli adattatori (ad es. LegacyDbSqlDatabase) per ottenere un legacyUser grezzo (). Il prossimo passo sarebbe quello di utilizzare un mappatore UserTranslator () e EmployeeTranslator () che converte i dati dell'utente legacy nella versione effettiva del dominio dell'entità User () e restituirli da UserFacade a UserEmployeeService, dove viene combinato con l'entità Dipendente proveniente dallo stesso posto.

Whoa, è stato un sacco di battitura a scrivere ...

Con gli adattatori e le facciate del tuo livello anticorruzione, puoi fare il tuo Linq-to-Sql o qualunque cosa tu voglia fare. Non importa perché hai completamente isolato il DB / sistema legacy dal tuo dominio bello e puro - il tuo dominio che ha la sua versione di entità User () e Employee () e oggetti valore.

Answer 2

DDD e Linq To SQL non vanno molto d'accordo perché le classi generate non devono discostarsi in modo significativo dalla struttura della tabella DB. Dovrai mappare le tue classi in un modo che rende difficile lavorare con Linq a SQL o semplicemente vivere con un modello a oggetti non ideale.

Se vuoi davvero utilizzare DDD e il modello di repository, scegli Entity Framework o ancora meglio NHibernate.