Approche pour concevoir des objets de service spécifiques ou génériques?

Question

Scénario: Utilisation d'une approche hiérarchisée avec les services WCF: services métier renvoyant des objets domaine/DTO au client. Toujours en développement, nous pouvons rompre les contrats.

Personne objet a son prénom et nom. L'objet membre possède le numéro de dossier fiscal et la date de naissance. C'est parce que, dans notre domaine, seuls les membres obtiennent les numéros de dossier d'impôt et les dates de naissance. Lorsque vous récupérez des données à partir d'un service à l'aide de cette structure, vous savez quels attributs sont applicables.

Maintenant, nous présentons un autre service qui a un usage pour les personnes dites Employé. Dans cet usage, l'objet Personne nécessite le numéro de fichier d'impôt des attributs supplémentaires et la date de naissance.

Quelle est la meilleure façon de procéder?

1) Traiter l'objet Personne comme une personne générique et inclure tous les attributs. Cela mappe la personne à une personne du monde réel, pas nécessairement basée sur l'utilisation. Cela signifie que les services qui renvoient des personnes incluront le numéro de dossier fiscal et la date de naissance, même s'ils peuvent ne pas être pertinents.

2) Dupliquer les champs supplémentaires dans Employee. Cela laisse la personne telle quelle et maintient les appels de service spécifiques au détriment de la duplication.

3) Créez un autre objet entre PersonWithDOBTFN dont nous héritons pour Member et Employee. Cela supprime la duplication, garde les choses spécifiques mais introduit de la complexité.

Je suis vraiment à la recherche d'une approche de meilleure pratique pour concevoir ces objets.

Answer 1

Il y a un problème avec ce que vous faites - il se décompose dans diverses circonstances. Le cas le plus évident immédiatement à partir de votre bref exemple est si une personne veut être un membre et un employé. Que se passe-t-il lorsqu'une personne ne veut plus être une employée et veut simplement redevenir une personne?

L'employé et le membre ne sont pas de vrais concepts "est un". Je peux être «un» employé ou un membre, mais ce n'est pas vraiment ce que je suis vraiment ou la base de mon identité en tant qu'entité. Membre et employé sont juste deux d'un grand nombre de rôles que nous occupons également dans le cadre d'être une personne.

Ne modélisez pas un rôle avec l'héritage, cela ne fonctionne pas correctement. Au lieu de cela, il suffit d'avoir une personne et d'ajouter une collection de rôles qui peut changer, prendre en charge plusieurs participations par une personne, etc.

Le reste ehhh.Mappez les attributs là où ils appartiennent logiquement, et non en fonction d'une politique ou d'une action précédente. Les services renvoient ce que vous voulez qu'ils retournent, la structure de données sous-jacente doit être logique et éviter la duplication.

Answer 2

Je serais tenté d'aller avec

Person ---is-a---> Member ---is-a--> Employee 

qui est en supposant qu'il ya quelque chose de nettement différent dans la façon dont « employé » fonctionne par rapport à « membre ». Il n'y a rien dans votre question pour l'indiquer mais je présume qu'il y aura des fonctionnalités supplémentaires dans l'employé que ce membre n'a pas. En ce qui concerne la complexité, je dirais qu'à ce stade de votre conception, c'est probablement quelque chose dont vous vous inquiétez prématurément. 2 niveaux de hiérarchie d'objets n'est pas seulement complexe - la plupart des systèmes de taille décente ont généralement plus de 2 niveaux si vous essayez de séparer la logique. Votre point sur la complexité est quelque chose que vous devriez penser plus au fur et à mesure que votre système se développe et s'il atteint des niveaux où cela devient beaucoup plus complexe que cela.