Quelle quantité de logique métier les objets Value doivent-ils contenir?

Question

Un des mentors que je respecte suggère qu’un simple haricot est une perte de temps: les objets de valeur «DOIT» contenir une logique d’entreprise pour être utiles.

Un autre affirme qu'un tel code est difficile à gérer et que toute logique métier doit être externalisée.

Je réalise que cette question est subjective. Demander quand même - vous voulez connaître les réponses de plusieurs points de vue.

Answer 1

Vous devriez plutôt les appeler objets de transfert ou Objets de transfert de données (DTO) .

Auparavant, ce même modèle j2ee était appelé "Objet de valeur", mais ils ont changé le nom car il était confondu avec ceci

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

Pour répondre à votre question, je ne mettrais qu'une logique minimale dans mes DTO, une logique nécessaire pour des raisons d'affichage.

Encore mieux, s’il s’agit d’une application Web basée sur une base de données, j’irais au-delà des modèles de base j2ee et utiliserais Hibernate ou API Java Persistence pour créer un modèle de domaine prenant en charge le chargement paresseux de relations et l’utiliser dans la vue.

Voir la Ouvrir une session dans la vue .

De cette manière, vous n'avez pas besoin de programmer un ensemble d'ODT et vous disposez de toute la logique métier à utiliser dans vos vues / contrôleurs, etc.

.

Answer 2

L'idée de rassembler des données et une logique métier consiste à promouvoir l'encapsulation et à exposer le moins possible d'état interne à d'autres objets. De cette façon, les clients peuvent compter sur une interface plutôt que sur une implémentation. Voir le principe "Dites, ne demandez pas" et le Loi de Demeter . L’encapsulation facilite la compréhension des états, la lecture du code, le découplage des classes et, en général, le test unitaire.

L'externalisation de la logique métier (généralement en classes "Service" ou "Manager") pose des questions telles que "Où ces données sont-elles utilisées?" et "Dans quels états peut-il être?" beaucoup plus difficile à répondre. C'est aussi une façon de penser procédurale, enveloppée dans un objet. Cela peut conduire à un modèle de domaine anémique .

Le comportement d’externalisation n’est pas toujours mauvais. Par exemple, une couche de service peut orchestrer des objets de domaine, sans toutefois assumer leurs responsabilités de manipulation d'état. Ou bien, lorsque vous effectuez principalement des lectures / écritures dans une base de données qui mappe parfaitement aux formulaires de saisie, vous n’avez peut-être pas besoin d’un modèle de domaine - ni de la surcharge douloureuse qu’il implique pour le mappage relationnel-objet.

Les objets de transfert servent souvent à découpler les couches architecturales les unes des autres (ou d'un système externe) en fournissant les informations d'état minimales dont la couche appelante a besoin, sans exposer aucune logique métier.

Cela peut être utile, par exemple lors de la préparation d'informations pour la vue: donnez simplement à la vue les informations dont elle a besoin, et rien d'autre, afin qu'elle puisse se concentrer sur comment afficher les informations plutôt que sur que quelles informations afficher. Par exemple, le TO peut être une agrégation de plusieurs sources de données.

Un avantage est que vos vues et vos objets de domaine sont découplés. Utiliser vos objets de domaine dans les JSP peut rendre votre domaine plus difficile à refactoriser et favorise l'utilisation aveugle des getters et des setters (d'où la rupture de l'encapsulation).

Toutefois, le fait de disposer de nombreux objets de transfert et souvent de la duplication entraîne également une surcharge. Certains projets auxquels j'ai participé se retrouvent avec des TO qui reflètent essentiellement d'autres objets de domaine (ce que je considère comme un anti-motif).

Answer 3

Cela dépend.

oups, est-ce que je viens de laisser échapper un cliché?

La question de base à poser pour concevoir un objet est la suivante: la logique régissant les données de l'objet sera-t-elle différente ou identique lorsqu’elle est utilisée / consommée par d’autres objets?

Si différents domaines d'utilisation appellent une logique différente, externalisez-la. Si c'est la même chose, peu importe la destination de l'objet, placez-le avec la classe.

Answer 4

Ma préférence personnelle est de placer toute la logique métier dans le modèle de domaine lui-même, c'est-à-dire dans le paramètre "true". objets de domaine. Ainsi, lorsque des objets de transfert de données sont créés, ils ne sont généralement qu'une représentation d'état (immuable) d'objets de domaine et ne contiennent donc aucune logique métier. Cependant, ils peuvent contenir des méthodes de clonage et de comparaison, mais le contenu du code de la logique applicative reste dans les objets du domaine.

Answer 5

Ce que Korros a dit.

Objet de valeur: = Un petit objet simple, comme de l'argent ou une plage de dates, dont l'égalité n'est pas basée sur l'identité.

DTO: = Un objet qui transporte des données entre processus afin de réduire le nombre d’appels de méthodes.

Ce sont les définitions proposées par Martin Fowler et je voudrais les vulgariser.

Answer 6

Je suis d’accord avec Panagiotis: le schéma de session ouverte en vue est bien meilleur que l’utilisation de DTO. Autrement dit, j'ai constaté qu'une application est beaucoup plus simple si vous trafiquez vos objets de domaine (ou un de leurs composites) depuis votre calque de vue vers le bas.

Cela étant dit, il est difficile de réussir, car vous devrez faire coïncider votre session HttpSession avec l'unité de travail de votre couche de persistance. Ensuite, vous devrez vous assurer que toutes les modifications de la base de données (création, mises à jour et suppressions) sont intentionnelles. En d'autres termes, vous ne voulez pas que la couche de vue ait un objet de domaine, qu'un champ soit modifié et que la modification soit persistée sans que le code d'application n'enregistre intentionnellement la modification. Un autre problème important à traiter est de vous assurer que votre sémantique transactionnelle est satisfaisante. En règle générale, l'extraction et la modification d'un objet de domaine s'effectuent dans un contexte transactionnel et il n'est pas difficile de faire en sorte que votre couche ORM nécessite une nouvelle transaction. Ce qui est difficile, c’est une transaction imbriquée, dans laquelle vous souhaitez inclure un deuxième contexte transactionnel au sein du premier ouvert.

Si cela ne vous dérange pas de rechercher comment une API non Java gère ces problèmes, consultez Active Record de Rails, qui permet aux pages de serveur Ruby de travailler directement avec le modèle de domaine et de parcourir ses associations.