Lutte avec DDD, modèle de référentiel et modèles de domaines associés

Question

J'ai vraiment du mal à comprendre ce que c'est. Permettez-moi de donner un exemple d'où je me bats. J'utilise Linq-2-Sql comme DAL pour mon application et le modèle IRepository utilisé dans l'exemple d'application MVC Storefront de Rob Conery.

Dans mon domaine, j'ai un modèle client qui a une collection de modèles d'adresses. Dans mon interface utilisateur, il y a un bouton qui permet à l'utilisateur d'ajouter une nouvelle adresse au client. Cela ouvre un éditeur d'adresses qui leur permet de remplir toutes les informations.

Que se passe-t-il ensuite? L'adresse est-elle enregistrée dans la base de données, puis ajoutée à la liste dans mon objet client? Est-ce que cela vient juste d'être ajouté à la liste mais pas mis à jour jusqu'à ce que l'objet Client soit enregistré? Que faire si l'utilisateur veut supprimer une adresse? Est-ce que je supprime l'adresse de la base de données, puis la supprime de la liste? Ou font-ils simplement tous les suppressions/ajouts qu'ils veulent et je vide tout de la base de données à chaque fois et la mise à jour avec ce qui est dans la collection Customer.Addresses? Quel est le bon flux ici?

Si la collecte d'adresses ne soient mis à jour via le référentiel en appelant quelque chose comme ceci:

public void AddAddressToCustomer(Customer c, Address a) 
{ 
    //validate and save address to db 
    //add the newly saved address to the Customer Object 
} 

Aide ...

Answer 1

DDD est un domaine où j'ai beaucoup d'intérêt, mais mais très peu d'expérience alors s'il vous plaît traiter mes suggestions avec prudence. Je ne les offre qu'à cause de l'absence d'autres réponses plus autoritaires.

Dans 'the book' par Eric Evans, l'adresse est donnée à titre d'exemple de quelque chose qui devrait normalement être traité comme un objet de valeur plutôt que comme une entité. Je crois donc que la méthode Add appartiendrait au client:

client.Add (adresse);

Il y aurait un référentiel client (mais pas un pour les adresses). Cela peut être utilisé comme ceci:

customerRepository.Update (client); L'effet intentionnel de ceci est que toutes les questions difficiles que vous posez sur la façon dont cela est ensuite implémenté sur la couche DB ne concernent pas les objets de domaine (c'est-à-dire l'objet client). J'ai peur que je ne puisse pas aider au-delà de ce point non plus.

Answer 2

On dirait que vous ne connaissez pas le contexte de votre domaine aussi bien que nécessaire. Posez d'autres questions et obtenez une meilleure histoire d'utilisateur. Il est possible que l'un ou l'autre de vos scénarios proposés réponde aux besoins de l'entreprise, selon ce que vous recherchez. Quand vous comprenez le besoin, je crois que cette question se résoudra.

Answer 3

cela dépendait d'un bon début de réponse. Une fois que vous ajoutez l'adresse au client et enregistrer le client à l'aide:

customer.Add(address); 
customerRepository.Update(customer); 

Votre dépôt serait alors map vos clients et adresse des entités de la couche de domaine à LINQ to SQL. Cela impliquera probablement la création d'un nouvel objet DataContext, l'obtention des entités LINQ to SQL associées (ou la création de nouvelles entités), puis le mappage des entités de la couche domaine vers vos entités LINQ to SQL.

var context = new MyDataContext(); 
var linqCustomer = MapCustomerToLinqCustomer(context, customer); 
var linqAddress = MapAddressToLinqAddress(context, customer.Addresses.First()); 
context.SubmitChanges(); 

Vous pouvez également utiliser les classes DataMapper pour la cartographie, mais les méthodes de MapXYZ plus suivre de près l'exemple de Rob Conery. Si vous avez besoin d'aide avec les méthodes MapXYZ, faites le moi savoir.