Questo probabilmente sembra un esempio di domanda basata sull'opinione pubblica, ma in realtà sto cercando una logica su come decidere correttamente, credo che ci sia una soluzione corretta che può essere sostenuta da argomenti solidi (ecco perché ho scelto SO e la speranza è in realtà non solo basata sull'opinione pubblica, ma posso sbagliarmi, se ti senti così, per favore lascia un commento in un commento). Non riesco a decodificare quanto lontano andare con SoC in DDD e se sia ok avere oggetti di dominio per lo più vuoti.
Abbiamo .NET, DDD, che utilizza principalmente EF come nostro ORM in repository, la nostra applicazione risiede in Azure. Per query complesse, utilizziamo stored procedure che restituiscono multiset (a causa di SQL di Azure): quindi una query = un round trip sul server (ne vale la pena, la query viene eseguita generalmente su > 10 tabelle separate, nessun join, quindi richiederebbe molti viaggi di andata e ritorno).
Per semplicità, immagina oggetto di dominio chiamato NavigationItem, che ha più titoli (in lingue diverse), gli elementi sono memorizzati in una tabella, i titoli localizzati sono memorizzati in un'altra tabella, dove la chiave esterna è il titolo dell'articolo contiene id cultura.
L'oggetto di navigazione potrebbe essere simile a questo:
public class NavigationItem
{
public int FileRecordId { get; set; }
public int? ParentId { get; set; }
...
public Dictionary<int, string> Title { get; set; }
}
Quindi l'oggetto dominio, restituito dal repository, viene costruito (nel repository) in questo modo:
// load list of navigation items
var reader = command.ExecuteReader();
navigation.Items = ((IObjectContextAdapter)_context).ObjectContext.Translate<NavigationItem>(reader).ToList();
// process localized titles
reader.NextResult();
var titles = ((IObjectContextAdapter)_context).ObjectContext.Translate<TitleInfo>(reader).ToList();
// associate titles, so the whole NavigationItem is constructed
foreach (var item in navigation.Items)
{
item.Title = titles.Where(t => t.FileRecordId == item.FileRecordId).ToDictionary(key => key.CultureId, value => value.Title);
}
Questo è un semplice esempio, giusto per ottenere il punto - la mia domanda è, non sarebbe meglio restituire solo la lista degli elementi di navigazione (dove dovrei omettere la proprietà Title) e l'elenco dei titoli e combinarli in un servizio livello, quando si crea un oggetto DTD? Il repository è responsabile della persistenza e del recupero dei dati persistenti, e non sono sicuro, se questo è semplicemente "troppo". D'altra parte, il requisito del repository potrebbe essere semplicemente "datemi l'intera entità con titoli". La separazione delle preoccupazioni è naturalmente un buon modo, ma non sono sicuro che si tratti ancora del deposito.
Per favore prendi questo come un semplice esempio, la mia domanda è più generale - in questo esempio, ogni oggetto di dominio NavigationItem contiene Title, quindi si sente che è OK farlo in repository. Ma quando abbiamo etities più complesse, c'è un altro problema - ad esempio, ogni file ha proprietà comuni, come Name. Alcuni file hanno proprietà immagine, lo stesso hanno anche proprietà documento PDF, alcuni hanno titoli localizzati ... altri no. In questo caso, sembra molto più "naturale" avere un'entità (file comune) e restituire lista, elenco, elenco, ... dal repository e combinarlo nel servizio. Oppure, d'altra parte, eseguire tutte le traduzioni nel repository, ma significherebbe che il file oggetto dominio (radice aggregata) conterrà entità come ImageInfo, TitleInfo, ecc., Che nella maggior parte dei casi saranno nulle.
Quale approccio - e principalmente, perché - consiglieresti?
EDIT: per essere più specifici - dal punto di vista del DDD, è ok mantenere Entity parzialmente vuota e qualche volta nel repository recupera solo alcune proprietà (o tutte quante volte), o è un approccio migliore per separare tale entità con quelle più piccole e restituire una entità che aggrega gli elenchi di tutte le possibili entità? Credo che ci possa essere una risposta ragionevole, tipicamente "sì, l'entità parzialmente inizializzata è ok", o "no, è sbagliato e dovresti sempre usare le entità granulari possibili", ecc.