Un oggetto dominio racchiude / contiene un'interfaccia DTO?

Question

Un oggetto dominio racchiude / contiene un'interfaccia DTO?

#1 da (4 voti)
#2 da (1 voti)

3

Usando .NET - Ho un'interfaccia IPerson. Questa interfaccia è implementata dalle classi in più repository separati, ad es. EF6 (EfPerson), SQL personalizzato (SqlPerson), o anche assembly personalizzati che si connettono a un servizio Web (WebPerson).

Assumendo un modello di dominio ricco, la mia idea è che il mio oggetto di dominio ricco adorabile "Persona" possa avere una variabile membro privata _PersonDto di tipo IPerson, fornita tramite costruttore. I membri della persona sarebbero l'unico modo per accedere ai dati dal _PersonDto.

Q. C'è qualcosa di intrinsecamente sbagliato in questo approccio? (Supponiamo che io non sia pigro nel caricamento e che possibilmente avrò un livello di servizio per le cose trasversali).

Si noti che sto usando DTO qui per indicare semplicemente gli oggetti anemici che torno dai miei repository.

domain-driven-design repository .net domain-model

posta Chalky 15.07.2014 - 00:04

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design repository .net domain-model

La licenza MIT mi consente di realizzare un prodotto front-end per un altro prodotto con licenza MIT? Unit test di dati caricati staticamente

score 4 · Answer 1

Un paio di osservazioni.

Primo, le classi (DTO o altro) dovrebbero essere agnostiche per la persistenza dei dati. In altre parole, non dovrebbero avere consapevolezza del loro meccanismo di persistenza dei dati sottostanti. Mi preoccupa che tu abbia tre diverse versioni di una Persona che si distinguono solo dal modo in cui sono memorizzate o recuperate.

In secondo luogo, le classi DTO sono semplicemente contenitori, utilizzati principalmente per lo spostamento di dati da un luogo a un altro. L'unico motivo per cui potresti impostarli tramite il costruttore è:

Volevi che fossero immutabili o
Volevi che fossero validi in istanza.

La convalida nei sistemi aziendali viene normalmente eseguita altrove (non deve necessariamente essere legata all'oggetto Person, sebbene sia possibile annotare oggetti con informazioni di convalida), e nei sistemi aziendali, in genere non vi è alcuna aspettativa di immutabilità (la maggior parte dei sistemi aziendali sono una grande massa di dati mutevoli e logica aziendale).

Quindi, per tutti questi motivi, dico che la risposta alla tua domanda è no.

score 1 · Answer 2

Non c'è nulla di sbagliato nell'approccio DTO dello stato di supporto, infatti è consigliato da alcune persone DDD.

Tuttavia, il popolamento di un oggetto dominio da fonti eterogenee non è la ragione principale per questo. Si tratta di risolvere il paradosso dell'incapsulamento dell'entità e della persistenza con un oggetto facilmente accessibile e mappabile da ORM.

EfPerson / SqlPerson / WebPerson e l'interfaccia IPerson non sono necessari IMO, perché l'oggetto dello stato di supporto è solo una borsa dati stupida che conterrà esattamente la stessa cosa in tutti i casi.

La raccolta dei dati e la logica di mappatura dovrebbero invece essere collocati in livelli di anticorruzione tra i vari sistemi di origine e il proprio sistema, o in diverse implementazioni concrete del Repository.