Les objets du modèle doivent-ils être flexibles

Question

[Désolé, mais le travail est propriétaire, je ne peux pas donner de détails sur les objets]

Je travaille sur une application Java avec un collègue. Je fais le côté client et il écrit le code du serveur.

L'application affiche une table d'objets X. Les colonnes du tableau montrent certains des attributs de X. De plus, nous avons une colonne qui montre un compte de Y pour chaque X. (L'association est plusieurs à un Y à X et dans un sens, Y a une référence à son parent X).

Le compte de Y n'est pas un attribut de X mais est obtenu via une requête sur le DB. J'utilise un TableModel donc il serait évidemment plus facile d'utiliser des objets X comme modèle pour la table. Mais puisque le compte Y n'est pas un attribut de X, je vais devoir créer un objet conteneur pour contenir un X plus un nombre. C'est plutôt ennuyeux car cela ajoute une classe qui semble inutile.

Je suggère à mon collègue qu'il ajouter un champ supplémentaire à X plus un getter:

informations privées vide Carte = new HashMap(); Cela rendrait les objets X du modèle plus flexibles. Je peux stocker n'importe quel état dont j'ai besoin à tout moment dans le client sans affecter les attributs principaux du modèle qui sont spécifiques à la nature de X. Les clés ne seraient définies que dans le client afin que le modèle ne soit pas pollué. Il a refusé car il estime que les objets du modèle ne devraient modéliser que le domaine et que le champ supplémentaire n'est pas lié aux objets du domaine et ne devrait donc pas être ajouté. Il pense que le client devrait gérer cela. Les deux points de vue semblent avoir du mérite, donc je serais intéressé par ce que les autres lecteurs pensent/ressentent à ce sujet.

Merci,

Tim

Answer 1

Je pense que vous confondez le modèle de base de données avec le modèle dans MVC. Gardez à l'esprit que le motif MVC est un motif de conception pour la couche de présentation. Le modèle, par exemple, dans MVC peut être le modèle de base de données (entités dans la base de données) dans une application simpliste mais cela n'est pas nécessaire. Je pense que vous devriez avoir une classe séparée (Table Model) comme vous l'avez dit qui devrait contenir les champs que vous affichez dans la Table. Ce modèle sera peuplé à partir de votre couche logique métier, c'est-à-dire, devrait être la sortie de votre BLL. Vous pouvez également appeler cela comme un DTO (Data Transfer Object). L'idée est de n'avoir que les données dont vous avez besoin. Si vous avez besoin du décompte, ne comptez que le nombre dans le DTO au lieu de Y. Cela permettra non seulement de gérer votre application, mais aussi de réduire le transfert de données entre les couches, réduisant ainsi l'empreinte mémoire de votre application et augmentant la performance aussi bien.

Answer 2

Je suis exactement dans la même position (je suis surtout le gars côté serveur) et je le vois comme votre collègue.

Dans notre cas, le côté serveur est un service Web. Vous ne savez jamais qui appellera le service à l'avenir donc je veux le garder aussi général que possible. Chaque fois que nous avons besoin de données spéciales dans le modèle, nous étendons les classes appropriées et les ajoutons de cette façon. Souvent, cela ne pose aucun problème puisque nous avons besoin de sous-classe de toute façon (par exemple, nous avons besoin de PropertyChangeSupport dans beaucoup de classes pour MVC).

Cependant, je ne sais pas si cela résout votre exemple 'count'. Nous avons également rencontré une situation similaire et je viens de créer un DTO spécial comme user446612 suggère que détient les données.

Answer 3

Merci pour les réponses les gars.

Tingu dit:

Je pense que vous confondez la base de données modèle avec le modèle MVC dans

Bon oui. Vous dites donc qu'il existe effectivement deux objets de modèle différents, un pour la base de données et un pour le M dans MVC dans l'application cliente, et que le modèle côté client est rempli par la BLL à partir des objets de modèle de base de données récupérés?

musiKk dit la même chose en lisant.

Nous utilisons le modèle côté serveur comme modèle de données (MVC M) dans le client et les objets sont simples.

musikk a donné la raison suivante:

Vous ne savez jamais qui appellerez le dans le futur service donc je veux le garder aussi général que possible.

C'est exactement l'argument avancé par mon collègue. Je suis entièrement d'accord que c'est essentiel. Cependant, je pensais qu'ajouter une carte d'objet au modèle ne rendait pas le modèle moins général. Il est fourni à titre de commodité pour le client et est une carte vide.

Les avantages sont les suivants:

(1) enregistre le client d'avoir à créer des sous-classes ou créer de nouveaux objets pour un simple cas comme celui-ci avec un seul champ supplémentaire

(2) très flexible état transitoire peut encapsuler avec l'objet tel qu'il est utilisé dans le client

les inconvénients sont les suivants:

(1) les objets sont plus gros qui le rend plus grand lors du déplacement à travers le réseau

(2) si vous sous-classe vous avez le champ supplémentaire même si vous ne l'utilisez pas