Comment empêcher plusieurs classes pour le même objet métier?

Question

Souvent, un objet métier possède une propriété pour un index utilisateur ou un ensemble d'index pour certaines données. Lorsque j'affiche cet objet dans un formulaire ou une autre vue, j'ai besoin du nom complet de l'utilisateur ou de certaines autres propriétés des données. En général, je crée une autre classe, myObjectView ou quelque chose de similaire. Quelle est la meilleure façon de traiter ce cas?

Pour clarifier davantage: Si j'avais une classe, un suivi des problèmes et que ma classe pour un problème a IxCreatedByUser en tant que propriété et une collection de valeurs IxAttachment (index pour les enregistrements de pièces jointes). Lorsque je l’affiche sur une page Web, je souhaite afficher John Doe au lieu d’IxCreatedByUser et un lien vers la pièce jointe et le nom du fichier sur la page. Donc, généralement, je crée une nouvelle classe avec une collection d'objets Attachment et une propriété CreatedByUserFullName ou quelque chose de ce genre. On se sent mal à créer cette deuxième classe pour afficher des données sur une page. Peut-être que je me trompe?

Answer 1

Le modèle de façade.

Je pense que votre approche, qui consiste à créer un motif de façade pour résumer les complexités de sources de données multiples, est souvent appropriée et rendra votre code facile à comprendre.

Il faut veiller à créer trop de couches d'abstractions, car le niveau d'indirection va ruiner la tentative initiale de rendre le code plus facile à lire. Surtout si vous sentez que vous écrivez juste des cours pour correspondre à ce que vous avez fait dans d'autres endroits. Par exemple, si vous avez myLoanView, vous n’avez pas nécessairement besoin de créer un myView pour chaque dialogue du système. Éloignez-vous du code de 10 pas et réalisez peut-être une façade qui est une abstraction intuitive et réutilisable que vous pourrez utiliser à plusieurs endroits.

N'hésitez pas à préciser la nature exacte de votre défi.

Answer 2

Un principe clé est que chacune de vos classes doit avoir un objectif défini. Si l'objet de votre "objet métier" Si la classe doit exposer les données pertinentes liées à l’objet métier, il peut être parfaitement raisonnable de créer une propriété sur la classe qui délègue la demande de description de recherche à la classe associée responsable de ces informations. Toute mise en forme spécifique à votre classe serait effectuée dans la propriété.

Answer 3

Voici quelques conseils pour vous aider à décider comment gérer ce modèle (assez commun, IMO):

1. Si vous avez simplement besoin d’un lien rapide vers une table de recherche qui ne change pas souvent (par exemple, une table d’adresses menant vers une table d’états et / ou de pays), vous pouvez conserver un fichier chargé paresseux. , copie statique de la table de correspondance.

2. Si vous avez une très grosse classe nécessitant beaucoup de jointures ou de sous-requêtes à charger uniquement à des fins d'affichage, vous souhaiterez probablement créer un " affichage " ou " info " classe à des fins d'affichage comme vous l'avez décrit ci-dessus. Assurez-vous simplement que la classe XInfo (pour l'affichage) se charge beaucoup plus rapidement que la classe X (pour l'édition). Il s’agit d’une situation où l’utilisation d’une vue côté base de données peut être une très bonne idée.