Conception de la couche de service DTO et DO

Question

Je suis en train de concevoir une nouvelle application à grande échelle qui doit être aussi flexible que possible.
J'ai choisi de concevoir principalement avec DDD ..
Ma question concerne le transfert d'objets DTO vers des objets DO dans ma couche de service.

i.e.: Ceci est mon objet de domaine mis en correspondance avec la DB (utilisant ORM)

public class Cat 
{ 
    int ID {get; set;} 
    string Name {get; set;} 
    string BloodType {get; set;} 
    string Color {get; set;} 

    void Run(){...} 
    void Purr() {...} 
} 

Méthodes et certaines propriétés ne sont nécessaires que pour les actions du serveur.
Voilà pourquoi je conçu un autre objet de transfert de données pour ce type de chat:

public class CatDTO 
{ 
    int ID {get; set;} 
    string Name {get; set;} 
} 

Au milieu, je vais mettre en place un mappeur objet de traduire mon DO de (et vice versa) de DTO.
Lorsqu'un client souhaite mettre à jour il appellera un service comme celui-ci

public void UpdateCat(CatDTO cat) 
{ 
    // What will happen here? 
    Cat serverCat = Mapper.GetCat(CatDTO); 

    CatDao.SaveOrUpdate(serverCat); 
} 

nom d'un chat Lorsque le mappeur traduit le DTO objet à le faire devra frapper la DB afin de combler le manque propriétés de l'objet Cat (type de sang, etc.) Aiguilles pour dire que cette action est absurde mais sans remplir les propriétés vides le reste du côté serveur ne peut pas fonctionner avec l'objet Cat car il dépend de ces propriétés manquantes (même si je essayer de mettre à jour les données dans la BD, My ORM mettra à jour le champ bloodtype sous la forme d'une chaîne vide!)
J'ai cherché ce problème et je n'ai trouvé aucune explication sur le web (ou au moins quelqu'un qui est ennuyé avec le problème comme je le fais)
Suis-je le concevoir dans le mauvais sens? Peut-être que j'ai raté quelque chose dans mon DDD?
Merci, Pavel.

Answer 1

Le flux de travail habituel pour ce cas d'utilisation est: récupérer l'objet de domaine mappé par ID, appliquer les mises à jour spécifiées par le DTO, valider l'unité de travail. Ce que vous appelez le DAO est normalement appelé référentiel dans DDD. Le code devrait ressembler davantage:

public void UpdateCat(CatDTO catDto) 
{ 
    Cat cat = this.catRepository.Get(cat.ID); 
    cat.Name = catDto.Name; 
    this.catRepository.Commit(); 
} 

L'étape Commit peut venir dans une variété de façons. Il peut s'agir d'une sauvegarde explicite ou l'unité de travail peut être validée en dehors de la méthode UpdateCat. Ce workflow s'applique également à tous les scénarios associés. Généralement, le comportement de domaine implique la récupération de l'entité appropriée, l'invocation d'un comportement sur cette entité et la validation des modifications qui en résultent dans la base de données. De même, les DTO ne doivent pas être mappés directement sur des entités existantes. Au lieu de cela, il est préférable de les considérer comme représentant les changements à appliquer aux entités existantes et le code devrait refléter cela. C'est en partie parce qu'une entité existante est «détenue» par le référentiel et que le référentiel est responsable de la reconstitution, et non d'un mappeur DTO.