Lors de l'utilisation de la conception de domaine, est-il préférable que les méthodes de vos services reçoivent une entité comme paramètre ou identifiant de votre entité comme paramètre afin que vous puissiez récupérer l'entité à l'intérieur de la méthode à l'aide d'un référentiel?
Par exemple: P>
public void Apply(int jobId, int userId)
5 Réponses :
Si vous envoyez l'objet, vous créez une dépendance entre le service et l'entité. L'un des avantages de l'utilisation de services consiste à agir comme façades pour réduire le graphique de dépendance entre les classes et réduire la complexité de la conception. Il est préférable d'utiliser des types primitifs, des structures, des énumjets dans des contrats de service, mais lorsqu'il s'agit d'un grand nombre de paramètres de méthode, vous pouvez les encapsuler dans un objet, mais dans ce cas, il s'agira d'une DTO et non d'une entité.
Et s'il passait dans une interface? Dites: appliquer (travail, utilisateur)?
@Adrian K Les mêmes avantages que j'ai expliqué dans ma réponse - ils sont des types de choses que c'est mieux que les primitives. La décision d'utiliser un contrat au lieu d'un béton dépendrait de votre conception / architecture. Cela n'est pas vraiment pertinent pour la question de savoir comment encapsuler des objets de modèle en tant que paramètres.
@Adrian Interfaces ne doit pas définir la structure mais le comportement.
@Cottsak: J'écris mes commentaires ici parce que c'est le seul endroit autorisé :) .. Les entités par définition doivent avoir un identifiant. Les objets sans identifiants sont des objets de valeur immuables de valeur tels que l'argent, l'adresse, .... Les services se produisent dans le modèle où est la nécessité de construire une barrière pour cacher des choses derrière et est destinée à être utilisée par des étrangers pour obtenir des informations sur ce qui est à l'intérieur. Il ne fait pas de différence si le service est utilisé pour la logique commerciale ou pour interfacer avec d'autres systèmes. Ce n'est qu'une question d'échelle ou de granularité.
@Cottask Si les entités extérieures se réfèrent aux entités situées derrière le service, vous obtiendrez des interdépendances partout. Si vous allez changer une classe, vous devrez examiner, modifier, compiler et tester tout.
@ M.Sameer Je ne sais pas que nous parlons du même type de "service". Si tel est le cas, cela provoque probablement une confusion dans cette question.
Pour ajouter à cette réponse, je conviens que le contrat de service devrait accepter des primitives, des études, des structures et des DTO - aucune entité. Cela permet à votre méthode de service de définir une portée transactionnelle transactionnelle d'entreprise claire dans laquelle vos actionnaires peuvent être résolus et mis en cache à utiliser dans ce cadre.
Dans ma compréhension, la différence n'est que le fait que le domaine fait avec l'utilisateur et le travail de faire une opération "Appliquer". Si l'ID est assez assez, il est acceptable de ne laisser que ID.
DDD consiste à cartographier le vocabulaire de votre client à votre conception. Votre client (espérons-le) parle des utilisateurs qui postulent à des emplois, et non quelques identifiants entier liés à un autre ID entier. Essayez de Coller au monde réel aussi près que possible que possible, à moins que cela ne devienne un fardeau. En passant dans toute l'entité, vous pouvez bénéficier immédiatement du comportement de l'entité, sans avoir à le construire d'abord . Soyez alors stick sur les entités, sauf si vous avez une situation où vous souvent seulement avoir un identifiant pour travailler. Cela se produit généralement lorsque vous traitez des systèmes externes , tels que des services Web. Dans ce cas, vous pouvez créer une surcharge de méthode qui accepte l'ID. Cette surcharge doit valider l'ID, construire l'entité et appeler la surcharge qui accepte l'entité. à nouveau: essayez d'éviter de telles surcharges autant que possible, à moins que vous n'êtes pas possible Traiter avec des systèmes externes qui ne renvoient que l'ID. d'un point de vue de codage, les entités sont également meilleures que les entiers. Un entier peut être de toute valeur entière, vous devez donc la valider partout que vous l'utilisez. Vos usines sont responsables de la construction d'entités valides et de votre logique (domaine) devraient conserver vos entités dans un état valide. Ainsi, l'utilisation de l'entité est totalement sûre et ne devrait pas nécessiter beaucoup de validation.
Cela dépend de où Votre service d'application réside:
Si votre service est exécuté dans la même appdomaine (c'est-à-dire que vous l'appelez à partir du même exécutable), puis passez l'objet est idéal. Le service peut facilement accéder à d'autres objets dans le graphique d'objet.
Si votre service s'exécute dans un Si vous essayez d'envoyer des objets sur le fil, vous avez probablement couru dans le problèmes décrits ici .
espère que cela aide.
J'utilise viewModel pour passer des "entités plats" vers / depuis un service d'application. Aussi, j'utilise le modèle de message de document pour communiquer avec le service d'application. Dans le service d'application, utilisez des méthodes d'extension pour des entités commerciales comme ceci:
public BusinessEntityViewModel ConvertToViewModel(this BusinessEntity businessEntity)
{
BusinessEntityViewModel bevm = new BusinessEntityViewModel{ Id = businessEntity.Id, ...}
return bevm;
}
C'est l'utilisateur
qui s'applique pour le travail, non? Que diriez-vous deutilisateur.apply (travail) . Je sais, qu'en est-il des services d'application? J'ai eu une discussion avec une foule Java et ils m'ont giflé autour de cela. DDD ne consiste pas à oublier OOP. Oui c'est l'utilisateurqui s'applique pour le travail.Regardez-y: code.google.com/p/ndddsample
@ryudice il serait certainement testable.
@Mikeeast tandis que votre suggestion de OO est un bon conseil La question est un peu plus abstraite - spécifiquement sur la manière dont les paramètres doivent être formés. D'accord?
@RYUDICE Serait la question la question plus claire: "Comment encapsuler une entité de domaine en tant que paramètre de méthode? ID INTEGER ou ENTTY STOOM?"