Sto progettando un'applicazione con DDD. Sto passando da oggetti POCO piatti a modelli di dominio forti, quindi la mia domanda è:
Dovrei chiamare le mie operazioni CRUD di base (situate nel mio livello di repository) direttamente dai controller, senza passare attraverso il livello del dominio? Non riesco a vedere alcun valore aggiunto per farlo, ma non sono sicuro che se è all'interno delle pratiche DDD effettui quella chiamata diretta.
Il tipico punto di ingresso per questo in DDD è un Servizio applicazioni . I servizi applicativi orchestrano le chiamate a repository e oggetti di dominio. Inoltre, conoscono lo stato di esecuzione corrente e spesso controllano la transazione aziendale generale attraverso un'unità di lavoro impegnata al termine del metodo di servizio.
Ad esempio:
Create new domain object
Add it to Repository
Commit UoW
or
Get domain object from Repository
Modify it
Commit UoW
etc.
Il servizio dell'applicazione può essere chiamato da un controller. In alcune implementazioni è il controller, quando le persone non vogliono disturbare un ulteriore livello di astrazione. Ma ciò può portare ad un Fat Controller.
my basic CRUD operations (located in my repository layer)
Mentre C, R e D fanno parte di un'interfaccia del repository, U non è necessario se si dispone di un'unità di lavoro. L'aggiornamento di tutte le entità di dominio modificate nella UoW verrà eseguito automaticamente su UoW.Save() .
Would I have to call my basic CRUD operations (located in my repository layer) from controllers directly?
No, non c'è niente che ti costringa o ti chieda di farlo. Puoi aggiungere tanti livelli tra il controller e il tuo database come desideri, oppure dividerlo in repository separati se lo desideri.
Would I have to call my basic CRUD operations (located in my repository layer) from controllers directly, without passing through the domain layer?
Penso che sia ok. Prendi nota che se la tua applicazione è divisa in tre livelli (interfaccia utente, logica di dominio e archiviazione), nel tuo caso l'interfaccia utente dipenderà sia dalla logica del dominio sia dai livelli di archiviazione.
Se la persistenza viene utilizzata solo dal livello logico del dominio, il livello dell'interfaccia utente viene lasciato solo in base al livello logico del dominio.
Senza vedere la tua applicazione effettiva è difficile dirlo, se è buono o cattivo.
Leggi altre domande sui tag domain-driven-design design-patterns patterns-and-practices asp.net-mvc mvc