mises à jour à l'entité, la conception de domaine

Question

Disons que j'ai un ordre qui a été mis à jour sur l'interface utilisateur avec certaines valeurs (ils pourraient être ok/pas ok pour assurer enregistrer)
1. Comment nous validons les modifications apportées? Le DTO qui porte la commande de retour à la couche service doit-il être validé pour être complet?
Une fois la validation terminée? Comment le service renvoie-t-il les erreurs de validation? Composons-nous un objet ReponseDTO et le renvoyons comme

ResponseDTO saveOrder (OrderDTO);

1. Comment mettons-nous à jour l'ordre des entités de domaine? L'assembleur DTO doit-il prendre soin de mettre à jour l'entité de commande avec les dernières modifications?

Si nous imaginons une approche hiérarchisée typique, ASP .NET sur le serveur Web, WCF sur le serveur d'applications. Lorsque le formulaire de commande est mis à jour avec des données sur le Web et enregistré. La WCF reçoit un OrderDTO. Maintenant, comment pouvons-nous mettre à jour la commande de DTO? Utilisons-nous un assembleur pour mettre à jour l'objet de domaine avec des changements de DTO? quelque chose comme

class OrderDTOAssembler { 
updateDomainObject(Order, OrderDTO) 
} 

Answer 1

Je vais essayer de répondre à certaines de vos questions de mon expérience et comment je devrais aborder votre problème. D'abord, je ne devrais pas laisser DTO effectuer des validations, mais simplement les DTO simples de POCO ont généralement des propriétés différentes avec des types de données spécifiques, donc une sorte de validation est faite. Je veux dire que vous devez appliquer un nombre de rue entier et une chaîne pour le nom de la rue, etc.

Deuxièmement, comme vous le faites remarquer. Laissez un ORderDTOAssembler convertir de OrderDTO en Order et vice versa. Ceci est fait dans la couche d'application.

Troisièmement j'utiliserais le modèle de visiteur Validation in a Domain Driven Design comme l'exemple. OrderService utilisera un IOrderRepository pour enregistrer/mettre à jour la commande. Mais en utilisant l'approche de validation des visiteurs, le OrderService appellera Order.ValidatePersistance (voir le lien dans l'exemple - mais il s'agit d'une méthode d'extension implémentée dans la couche infrastructure puisqu'elle a la "connaissance db"). Si vrai, alors nous à IOrderRepository.Save (commande). Enfin, si Order.ValidatePersistance échoue, nous recevons un ou plusieurs messages BrokenRules. Ceux-ci devraient être retournés au client dans un ResponseDTO. Ensuite, Cient peut agir sur les messages et agir. Problème ici peut être que vous aurez un message ResponseOrderDTO mais peut-être (juste venu avec ceci maintenant) tout votre ResponseDTO peut hériter de la classe ResponseBaseDTO qui exposent les propriétés nécessaires pour livrer des messages BrokenRule. J'espère que vous trouverez mes pensées utiles et bonne chance.