DDD avec EF Premier Code comment faire pour les mettre ensemble?

Mise à jour je n'ai plus de plaider pour l'utilisation des "objets de domaine" et au lieu de préconiser une utilisation d'une messagerie à base de modèle de domaine. Voir ici pour un exemple.

La réponse à la n ° 1 est ça dépend. Dans toute application d'entreprise, vous allez trouver 2 grandes catégories de choses dans le domaine:

Droite CRUD

Il y a pas besoin d'un objet de domaine ici parce que le prochain état de l'objet ne dépend pas de l'état antérieur de l'objet. C'est l'ensemble des données et pas de comportement. Dans ce cas, c'est ok pour utiliser la même classe (c'est à dire un EF POCO) partout: de l'édition, de la persistance, de l'affichage.

Un exemple de ceci est l'enregistrement d'une adresse de facturation sur une commande:

public class BillingAddress {
  public Guid OrderId;
  public string StreetLine1;
  //etc.
}

D'autre part, nous avons...

Machines D'État

Vous avez besoin d'avoir objets séparés pour le domaine du comportement et de la persistance de l'état (et un référentiel de faire le travail). L'interface publique sur le domaine de l'objet devrait presque toujours être toutes les méthodes void et pas de public getters. Un exemple de ceci serait de statut de la commande:

public class Order { //this is the domain object  
  private Guid _id;
  private Status _status;

  //note the behavior here - we throw an exception if it's not a valid state transition
  public void Cancel() {  
    if (_status == Status.Shipped)
      throw new InvalidOperationException("Can't cancel order after shipping.")
    _status = Status.Cancelled;
  }

  //etc...
}

public class Data.Order { //this is the persistence (EF) class
  public Guid Id;
  public Status Status;
}

public interface IOrderRepository {
  //The implementation of this will:
  //1. Load the EF class if it exists or new it up with the ID if it doesn't
  //2. Map the domain class to the EF class
  //3. Save the EF class to the DbContext.
  void Save(Order order); 
}

La réponse à la n ° 2 est que la DbContext va automatiquement suivre les modifications apportées à EF classes.

OriginalL'auteur

Pluralsight cours: Entity Framework dans l'Entreprise va dans ce scénario exact de Domain Driven Design incorporated avec les objectifs EF Premier Code.

Pour le numéro 1, je crois que vous pouvez le faire de toute façon. C'est juste une question de style.
Pour le numéro 2, l'instructeur dans la vidéo passe par un couple de façons de rendre compte de cela. Une façon est d'avoir un "État" de la propriété sur à chaque classe qui est situé sur le côté client lors de la modification d'une valeur. Le DbContext sait alors quels sont les changements à persister.

OriginalL'auteur