Architecture: come passare modelli tra controller, servizi e repository

Question

Architecture: come passare modelli tra controller, servizi e repository

#1 da (1 voti)
#2 da (0 voti)

2

Sto provando a costruire un'architettura in cui dispongo di un progetto di dominio con tutti i miei modelli di dominio, un progetto di infrastruttura con i miei servizi e infrastruttura.Entità con i miei archivi ed entità.

Tuttavia, sono un po 'confuso su quale sia il modo migliore per passare oggetti tra i diversi livelli.

Il livello di presentazione conosce solo il dominio e il livello / infrastruttura di servizio e passa gli oggetti dominio al servizio. Ed è qui che sono in dubbio.

Diciamo che ho:

DomainProduct
EntityProduct
ProductController
ProductService
ProductRepository

Domanda: Dove mappare gli oggetti tra i modelli di dominio e le entità? Io chiamo il servie con un modello di dominio, ma il servizio chiama il repository con un modello di dominio, o lo mappo a un'entità e chiamo il repository con quello?

Controller - > Modello di dominio - > Servizio
Servizio - > Modello di dominio - > Repository

o

Servizio - > Entità - > Repository

(e vice-versa)

Caso: eliminazione di un prodotto

Qui chiamerei semplicemente il servizio dal controller con l'ID del prodotto che deve essere cancellato. Quindi il servizio:

Chiama Elimina (id) nel repository

o

Ottiene il prodotto dal repository tramite l'ID
Chiama il metodo delete sul repository con il modello?

Tuttavia, non è una voilà in DDD? Devo prima ottenere DomainProduct dal livello di servizio, quindi chiamare Delete con quel DomainProduct? Questo sembra ridondante e non necessario.

Sono un po 'confuso su come è fatto meglio. Mi piace molto l'ID e le entità che passano tra il servizio e il repository. Ma penso che sia una violazione.

Puoi aiutarmi?

c# domain-driven-design entity-framework orm onion-architecture

posta Trolley 11.09.2016 - 10:44

fonte

2 risposte

Leggi altre domande sui tag c# domain-driven-design entity-framework orm onion-architecture

Coda messaggi tra server e motore Dove inserire una logica di convalida estesa in DDD

score 1 · Answer 1

Se osservi il pattern CQRS noterai che le operazioni del dominio si riducono ai comandi. In questo caso, vedrei completamente bene definire un comando delete come solo richiedendo l'ID. Anche l'utilizzo di questo modello ti consente di ottenere una flessibilità completa nella modalità di rappresentazione dei dati e di non collegarne uno al modo in cui sono strutturate le entità di dominio.

Quindi potrebbero esserci alcuni casi in cui un'operazione contro un dominio ne richiederebbe l'eliminazione. Supponiamo che tu abbia una coda di posta elettronica e che un articolo raggiunga la soglia di invio. Si potrebbe quindi sostenere che è possibile verificare se la soglia è stata raggiunta e fornire l'oggetto al repository e farlo eliminare in questo modo.

Una cosa di cui mi sarei stancato sarebbe di consentire al controller di accedere direttamente agli oggetti Dominio. Preferibilmente si preferirebbero che le manipolazioni dei domini venissero eseguite dal livello aziendale e solo i Controller (che dovrebbero essere responsabili dell'interfaccia utente) piuttosto) essere in grado di comunicare di conseguenza con il livello aziendale.

score 0 · Answer 2

Idealmente, hai separare modelli di dominio e oggetti di trasferimento dati (DTO). Il modello di dominio è un modello per livello o dominio . Ad esempio, il livello dell'interfaccia utente e il livello della logica aziendale devono avere i propri oggetti dominio.

Usi DTO per passare "dati" tra i livelli.

[UI Layer] <- UserDto -> [Business logic layer]

L'atto di convertire gli oggetti del dominio in DTO e di nuovo nell'altro lato viene generalmente chiamato "mappatura degli oggetti". Librerie come AutoMapper sono utilizzate per semplificare il processo.