Interfacce del repository contenute nel progetto Core anziché nel progetto Intrastructure

3

Stavo guardando un progetto di recente, che contiene i seguenti progetti di Visual Studio:

App.Web
App.Core
App.Infrastructure

Le interfacce del repository erano contenute nel progetto Core e le classi di repository (implementazioni) erano contenute nel progetto Infrastruttura. Perché dovresti inserire le interfacce Infrastructure in un progetto separato? Il codice cliente (o IOC) deve fare questo:

Core.ICustomer Repository = new Infrastructure.CustomereRpository()

Qual è il vantaggio di farlo?

Se introducessi un servizio applicativo (in modo da poter introdurre più client), allora le interfacce si terranno nello stesso posto, cioè il core?

Ho letto domande come questa: link . Tuttavia, non sono ancora chiaro perché le interfacce siano contenute nel Core.

Sto anche cercando di capire la differenza tra un progetto chiamato: app.Core e un progetto chiamato: app.Domain. Sto vagando se app.Core contiene più del dominio?

    
posta w0051977 15.07.2017 - 15:48
fonte

2 risposte

3

Qualsiasi classe di repository DEVE fare riferimento al progetto principale per restituire i Modelli che contiene.

Pertanto, è un posto sensato per mettere l'interfaccia del repository.

Inoltre le classi di business logic possono richiedere il funzionamento di un'istanza di un IRepository.

Se dovessero fare riferimento a un progetto dipendente dall'infrastruttura per farlo, otterresti riferimenti circolari. Quindi, ancora una volta, il progetto di base o dei modelli è una buona scelta.

Ora, se aggiungi altri progetti di servizi di logica aziendale isolata, con potenziali implementazioni concrete multiple in cui inserisci l'interfaccia per quel servizio è una domanda interessante.

  • core: pratico e facile, ma ora devi aggiornare la libreria di base ogni volta che pensi a un nuovo servizio.

  • myService: pratico e facile, ma non adatto per l'espansione futura a una seconda implementazione concreta

  • myServiceInterface: un bizzarro progetto mobile con un solo file. non carino

  • myBigInterfaceLibrary: un bizzarro progetto mobile che devi aggiornare continuamente.

Normalmente vado con il core o myService. puoi sempre spostarti da myService a myServiceInterface in seguito, se necessario.

I repository sono un caso un po 'particolare in quanto sai che li avresti e sai che saranno dipendenti dall'infrastruttura proprio all'inizio del progetto

    
risposta data 15.07.2017 - 16:09
fonte
2

What is the benefit of doing this?

Una cosa da tenere a mente è che l'applicazione, il modello di dominio e la persistenza evolvono ciascuno a un ritmo diverso dagli altri. Si prevede che il dominio sia in grado di supportare più applicazioni; e dovresti essere in grado di revisionare frequentemente l'implementazione all'interno del dominio, ma la persistenza generalmente si evolve più lentamente, perché non eliminiamo lo stato accumulato ogni volta che aggiorniamo il modello.

The Repository interfaces were contained in the Core project and the Repository classes (implementations) were contained in the Infrastructure project.

Bene, l'interfaccia del repository è il contratto che definisce l'accordo tra l'applicazione e il modello di dominio (che è esso stesso che incapsula il componente di persistenza dietro di esso). Quindi ha un certo senso che quelle interfacce siano nel core o nell'applicazione - se non le si estraggono separatamente, e ci si aspetta di supportare più applicazioni, il core è la casa naturale per loro. / p>

Per quanto riguarda dove vanno le implementazioni, questo diventa un po 'più complicato. Le entità e i valori nel tuo modello di dominio hanno due rappresentazioni logicamente distinte: quella che vedi in memoria e quella che vedi nel tuo negozio durevole (pensa gli oggetti in memoria rispetto alle righe in un RDBMS).

Quello che Evans ha descritto nel libro blu è che il ruolo del repository è quello di fornire l'illusione che gli aggregati vivano tutti nella memoria. Quindi è ragionevole pensare al repository come un'interfaccia del fornitore di servizi, con il componente dell'infrastruttura come fornitore di servizi responsabile della decisione su come serializzare / deserializzare i dati verso / dal libro del record.

CQRS aiuta a rendere chiara questa separazione; poiché i casi di utilizzo di lettura e scrittura differiscono, anche i ruoli definiti per il repository sono diversi. In particolare, non sorprende che potremmo decidere che un particolare caso d'uso vuole un tipo specifico di archivio dati: un archivio documenti per fornire rappresentazioni memorizzate nella cache di viste o un database grafico per query veloci di un social network.

In questo tipo di design, questa modifica è semplice: basta scambiare l'implementazione di persistenza specifica e le modifiche alle applicazioni e ai modelli di dominio sono minime; l'infrastruttura cambia molto (sostituzione completa all'interno di tale caso d'uso) e la composizione di root un po '(sostituendo un modulo di persistenza con un altro), ma il modello e l'applicazione non sono interessati dalla modifica.

Naturalmente, può essere più complicato: nei sistemi basati su eventi, di solito hai una rappresentazione degli eventi nel tuo archivio di eventi durevoli, che può o meno allinearsi con la rappresentazione di eventi in memoria, che a loro volta sono distinti dalle rappresentazioni degli aggregati che si utilizzano quando si calcolano nuovi eventi. In questo tipo di sistema, la componente di persistenza normalmente riguarderebbe la scrittura di eventi da e verso l'archivio eventi, in cui le traduzioni delle cronologie degli eventi da e verso gli aggregati vivrebbero nel modello di dominio (es .: core).

    
risposta data 16.07.2017 - 04:56
fonte

Leggi altre domande sui tag