Livello infrastruttura DDD: implementa il servizio + persistenza o semplicemente persistenza

Question

Livello infrastruttura DDD: implementa il servizio + persistenza o semplicemente persistenza

#1 da (3 voti)
#2 da (1 voti)

2

Breve introduzione: costruisco un'applicazione, utilizzando .NET, Entity Framework (EF) come ORM e SQL Server per la persistenza. La mia conoscenza di SQL Server va ben oltre le semplici richieste e io la uso per ridurre drasticamente le operazioni di DB. Comunque preferisco usare EF per tagliare scrivendo direttamente SQL quando possibile.

Ho un servizio di applicazione, per esempio IDogsService, che vorrei implementare nel nucleo. L'implementazione avrà il contesto EF (un repository) iniettato e dovrebbe usare il contesto iniettato per la persistenza. Questo è ciò che ritengo dovrebbe essere la mia architettura, secondo DDD.

Ma faccio tutto diversamente. Mentre l'interfaccia IDogsService è nel nucleo - l'implementazione è in un altro progetto. E quell'implementazione non ha iniettato alcun repository, semplicemente usa un contesto db interno, definito nello stesso progetto. La ragione di tale decisione è semplice: mentre il core non sa nulla del repository, l'implementazione di IDogService può comportarsi come vuole, quando si tratta di persistenza. E credo che il nucleo non dovrebbe preoccuparsi affatto dei repository.

Professionisti di tale approccio: il mio contesto db è in grado di utilizzare tutti i vantaggi di SQL Server, aumentando quindi le prestazioni. Contro: la logica di business del servizio viene spostata fuori dal centro (penso che dovrebbe rimanere nel nucleo).

Ho una strong sensazione che tutto questo è sbagliato e dovrebbe essere architettato un po 'diverso. Ma non so come. Non voglio davvero rivolgermi a uno schema di repository, poiché eliminerà i vantaggi di SQL Server a favore di altri RDBMS.

Qualche esperienza da condividere?

domain-driven-design services entity-framework persistence

posta Dima 23.05.2017 - 22:27

fonte

2 risposte

1

Credo che tu sia il livello aziendale con livello di accesso ai dati. Avere IDogService fare business logic E usare un contesto per scrivere le chiamate db è una violazione di SPR. Sembra che quello che in realtà desideri sia separare il livello di accesso ai dati dal livello del dominio, ma non puoi farlo senza astrarli ... ergo il modello del repository.

Crea un'implementazione di IDogService ( DogService ) solo per logica aziendale e fallo dipendere da un IDogRepository . Mantieni quelle 3 classi nel Core, pur avendo DogRepository sul diverso progetto. Risolvi 2 problemi: 1 violazione SPR e ora puoi facilmente passare a Posgress senza dover violare il principio Apri / Chiuso anche su DogService quando lo fai.

risposta data 24.05.2017 - 00:05

fonte

Leggi altre domande sui tag domain-driven-design services entity-framework persistence

Gestione dello scaffolding per build di debug e di produzione Qualsiasi vantaggio nell'utilizzo di più sistemi di compilazione? [chiuso]

score 3 · Accepted Answer

Mi sembra che tu ti stia distorcendo attorno al principio di inversione delle dipendenze .

Suggerirei di dare il saggio 2009 sui repository generici di Greg Young una lunga lettura Il TL; DR è che nei casi comuni preferisce un contratto con definizioni esplicite.

Udi Dahan, scrivendo qualche anno prima, aveva idee simili .

Ma la trama di base è che il codice di dominio descrive le sue esigenze di dati nel modo esplicito che può attraverso le interfacce di contratto. Le componenti di persistenza forniscono implementazioni che soddisfano tali contratti nel modo più efficiente possibile e le radici di composizione collegano tutto insieme .

Cons: service's business logic is moved out of the core

Sono d'accordo che sarebbe un aspetto negativo, ma non dovrebbe accadere, a meno che non si stia tentando di specificare l'implementazione della soluzione di persistenza nel modulo aziendale.

Of course, I can revert to repository pattern, to become DB agnostic, but I will loose in performance

No no no; L'agnostico di DB è OK - sono (probabilmente) i contratti vaghi che non forniscono sufficienti informazioni per metterti nei guai.

Mantenere le preoccupazioni separate; ma rendi il contratto sufficientemente esplicito che le implementazioni che riconoscono che un caso d'uso è perfetto per alcune funzionalità possono trarre vantaggio.

Spesso, questo modello sembra un'interfaccia che descrive ciò che è necessario al dominio principale, un'implementazione ottimizzata che può fare bene il lavoro e un adattatore sottile nel mezzo che comprende come negoziare tra i due.

Il blog di Mark Seemann include anche un buona panoramica sulle dipendenze .