Il modello di repository con Domain Driven Design diventa Anti-Pattern?

Question

Prima di tutto voglio chiarire che sono nuovo a Domain Driven Design e sto facendo questa domanda perché ho letto qualcosa chiamato Anemic Domain Model.

La maggior parte delle volte vedo la seguente cosa mentre si lavora con il modello di repository.

1. ne abbiamo una generica Repository
2. Abbiamo modello che solo contengono insieme di proprietà pubblica, ma non contiene alcun metodo (So It diventare anemici Domain Model come da definizione di DDD) perché la classe qui repository gestire altri processo per quell'entità o modello.

Si prega di fornire la vostra risposta preziosa per la mia richiesta.

Permettetemi di chiarire alcune cose.

Repository generico indica un'interfaccia generica che viene implementata dal repository Entity.

La mia confusione è per quanto riguarda cosa seguente

Per esempio: Supponiamo che io voglio salvare

public class User 
    { 
     public int Id { get; set;} 
     public string Name { get; set}; 
    } 

    public class UserRepository : IRepository<User> 
    { 
     // All Operation Like Save/Get/UserEntity (Domain Object)  
    } 

Così qui è la mia classe per l'utente non fare nulla invece solo hanno proprietà e altra maniglia operazione UserRespository. Quindi il mio utente è un modello di dominio anemico. (Come non fa nulla di specifico)

Qui in immagine allegata, considero ProductRepository quindi la mia domanda è: la mia classe di prodotto è un modello anemico?

Considerare la seguente immagine di esempio per ciò che sto cercando di dire.

Answer 1

Il pattern repository non è un anti-modello di per sé, ma ho visto lontano per molte implementazioni di DDD dove il modello repository disponibile poco o nessun valore. Consegnate la vostra architettura a livelli n-tier-no-value a un esperto pragmatico di esperti hardcore e probabilmente vi darà la critica "anti-modello" (e valido potrei dire).

Repository pro modello:

1. Un'astrazione della tecnologia di persistenza sottostante
2. Una possibilità di definire le radici di aggregazione, solo radici di aggregazione dovrebbero avere repository
3. Un modo di affermando esplicitamente che le operazioni sono validi per la radice aggregata in questione, ad esempio se non è valida per eliminare la tua entità, il tuo repository non dovrebbe avere alcun metodo di cancellazione.
4. Qualcosa che è facile testare senza un database (spegnendo i repository) contro modello

Repository:

1. vicinanza alla vostra tecnologia di persistenza.
2. Ancora, un altro livello

Personalmente preferisco utilizzando il modello repository quando si fa DDD, ma la soluzione suona più come il modello di record attivo, eliminando in tal modo la maggior parte dei vantaggi di utilizzare i repository, in primo luogo. Non faccio mai repository generici perché rimuovono i professionisti 2 & 3 (Posso avere un'implementazione generica, ma non la esporre direttamente al codice repository-consumer).

E ancora: non utilizzare i repository per la popolazione di DTOs, ViewModels, ecc utilizzano modelli e tecnologie per la modellazione separati scrive (DDD può funzionare grande) e legge.

Answer 2

Sono d'accordo che l'interfaccia IRepository è generalmente una perdita di tempo. Se inserisco le operazioni CRUD di base nell'interfaccia IRepository, come faccio a gestire dati come i dati di controllo? Dove eliminarlo sarebbe proibito. Dovrei semplicemente restituire un InvalidOperationException quando provo a chiamare Delete()?

Alcune persone hanno suggerito interfacce più piccole come IReadable, IWriteable, IUpdateable o IDeleteable. Penso che questo approccio sia ancora più confuso.

Personalmente (e questa è solo la mia soluzione dopo aver dato a tutto il resto una buona corsa intorno al blocco), per DDD, preferisco usare un'interfaccia per repository (principalmente per IoC e test di unità). Questo mi dà IUserRepository, IAuditLogRepository, ecc. I miei repository accettano anche (come parametri) e restituiscono entità di dominio (radici aggregate o solo singole entità). In questo modo non ci sono oggetti DTO anemici per mantenere o ingombrare la mia soluzione. Tuttavia, utilizzo ancora i modelli di visualizzazione per mantenere i dati sensibili fuori dalle mie visualizzazioni.

C'è un sacco di argomenti online a favore e contro il modello di repository.