Va bene avere una factory di dominio speciale - o qualcosa di simile - direttamente in DAL?

Question

Va bene avere una factory di dominio speciale - o qualcosa di simile - direttamente in DAL?

#1 da (1 voti)

0

Nell'applicazione DDD, so che Domain Factory dovrebbe essere il singolo punto di creazione dell'oggetto Dominio (input dall'interfaccia utente, i risultati delle query di persistenza) - ma sto affrontando un problema che per query molto complesse, usiamo stored procedure con più insiemi di dati - quindi i dati sono tradotti in strutture (classi) altamente dipendenti dall'implementazione della persistenza, ad esempio

var reader = command.ExecuteReader();

... processing many record sets

reader.NextResult();
var userRows = ((IObjectContextAdapter)_context).ObjectContext
               .Translate<UserRow>(reader).ToList();

In questo caso, userRows contiene una tabella di utenti rilevanti (solo poche colonne rilevanti da una tabella altrimenti molto complessa). E fino al punto - fino ad ora, usiamo la classe statica DomainModelHelper definita in DAL, che in questo caso, ad es. da ID (ottenuto dalla diversa tabella nella stessa query) e userRows crea l'oggetto dominio UserInfo (che contiene le informazioni di base sull'utente), ad es.

// here we create aggregate root
...

foreach (var something in somethingRows)
{
    var createdBy = DomainModelHelper.CreateUserInfo(something.CreatedById ?? 0, userRows)
    ...
    // add this domain object to aggregate root
}

Questo può funzionare, ma per qualche ragione, questo non sembra giusto. C'è qualche altro - migliore - schema o approccio di cui sono a conoscenza?

domain-driven-design repository

posta Robert Goldwein 14.10.2014 - 00:48

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design repository

Tipo di licenza del software con funzionalità gratuite e funzionalità aggiuntiva di prova Nessuna coordinata ripetuta nel complesso di walker casuale

score 1 · Accepted Answer

Il repository è responsabile dell'idratazione e disidratazione delle radici aggregate. Pertanto, è responsabile della creazione del grafo degli oggetti dalla radice aggregata fino a tutte le sue entità figlio e oggetti valore. Il fatto che il codice utilizzato per farlo è separato in una classe helper non esclude il fatto che il repository sta ancora facendo il suo lavoro.

Il domain factory è pensato per il codice dell'applicazione che sta cercando di creare nuovi oggetti di dominio e definisce i requisiti per ciò che è necessario per creare un'istanza di una nuova radice aggregata, ma non è relativo alla persistenza.

Pensa a questo, quando acquisti un'auto, hai bisogno di soldi, una licenza e un'assicurazione. Quindi, la concessionaria è come una fabbrica di domini. Non puoi avere una macchina nuova finché non hai quelle cose. Tuttavia, se conservi la tua auto nel tuo garage, quando vai a recuperare la tua auto dal tuo garage, ti aspetti che sia nella stessa identica condizione in cui si trovava quando la metti lì. Il repository è come il tuo garage.