Création d'objet WCF - POO vs SOA

Question

Quelle est la bonne façon de gérer les objets métier polymorphes dans un monde WCF/SOAP?

Il me semble que SOA et OOP sont en désaccord les uns avec les autres - pour exposer un WSDL propre, vous avez besoin d'objets concrets, typiquement n'utilisant même pas l'héritage. D'autre part, probablement dans le système sous-jacent, vous voudrez suivre la conception OO appropriée.

Que font généralement les gens ici? Construire un ensemble d'objets de contrat WCF, en renonçant aux principes de la POO, puis convertir vers et à partir d'un autre ensemble d'objets dans les couches logiques réelles?

Answer 1

Que font généralement les gens ici? Construire un ensemble d'objets de contrat WCF, en renonçant aux principes de la POO, puis convertir vers et à partir d'un autre ensemble d'objets dans les couches logiques réelles?

Oui.

La manière dont WCF sérialise les objets finit par mettre beaucoup de limitations sur ce que vous pouvez et ne pouvez pas faire avec les objets du contrat. Ce que vous ne pouvez pas faire finit par être «la plupart des choses utiles».

J'ai trouvé que cela rend les choses beaucoup plus claires si vous considérez les objets de contrat WCF comme un simple mécanisme de transfert de données. Fondamentalement comme XML fortement/statiquement typé.
Au lieu de convertir votre objet métier en une chaîne XML (et inversement), vous convertissez votre objet métier en un objet WCF-contrat (et inversement), mais il est similaire

Answer 2

Après avoir lu la bibliothèque Thomas Erl, je suis venu à la conclusion suivante:

Pensez du message Les contrats WCF/SOAP comme simplement un message que les services utilisent pour communiquer (ne pas attacher étroitement que aux objets dans les votre code).

Vous pouvez ensuite utiliser la POO pour concevoir une base de code qui gère avec élégance ces messages en utilisant des techniques de POO courantes.

Answer 3

Vous utilisez une abstraction (type d'interface) annotée avec des attributs WCF afin de définir votre contrat de service.

Cela dépend à la fois de l'abstraction, qui est conforme à la POO, et de la définition d'un point de terminaison de service, SOA.

En général, si vous constatez que vous obtenez des objets métier avec des dépendances, vous devez envisager d'extraire ces dépendances jusqu'à la couche de gestion de service, au lieu d'injecter des dépendances dans les objets métier. La couche de gestion de service agira alors en tant que médiateur agissant à la fois sur le proxy de service WCF et sur les objets métier. Au lieu d'avoir les objets métier agissant sur le proxy de service WCF.

Answer 4

Tous les excellents commentaires à ce sujet! Je vais ajouter mon vote à la notion d'un adaptateur pour la médiation entre votre orientation de service et l'orientation de l'objet. J'aime aussi l'approche de Thomas Erl où, dans son modèle de service, il introduit la notion de «services applicatifs» et de «services aux entreprises». C'est la voie à suivre pour vos points d'intégration avec votre environnement applicatif/métier spécifique (c'est-à-dire votre framework/API orienté objet et orienté composant). De cette façon devrait aboutir à une meilleure composabilité et donc une meilleure capacité, pour vous les gourous du cadre d'entreprise là-bas.