Existe-t-il des bonnes pratiques en matière de sérialisation des graphes d'objets à l'aide de WCF ?

Question

J'utilise WCF avec Entity Framework v4 et j'utilise des entités POCO. Nos entités ont un grand nombre d'entités liées. Un objet peut avoir de nombreux objets enfants d'un type différent qui, à leur tour, ont de nombreux enfants de types différents. Par exemple, une voiture a un ou plusieurs conducteurs. Chaque conducteur a 0 ou plusieurs enfants. Chaque enfant a ensuite 0 ou plusieurs amis. (Pauvre enfant avec 0 ami). L'exemple est un peu idiot mais vous avez compris.

Si le client voulait demander une voiture, il serait logique de lui rendre la voiture avec la liste de ses conducteurs. Il pourrait ou non être logique de remplir et de renvoyer les enfants de chaque conducteur. Et le problème n'en finit pas.

Parce que votre base de données est presque toujours constituée uniquement de tables interconnectées (conduisant à des entités interconnectées), quelle part du graphe d'objets doit-on sérialiser ?

• Existe-t-il une meilleure pratique en matière d'AOS ?
• Devrait-il s'agir uniquement des entités immédiatement liées ?
• Y a-t-il une sorte de convention d'appellation ?
• Devons-nous utiliser des méthodes différentes, par exemple GetCar() et GetCarWithDrivers() ?

Answer 1

Je ne pense pas qu'il existe de règle empirique et je n'aime pas l'idée de renvoyer des données dont le client n'a pas besoin. La conception de votre service doit être guidée par la fonctionnalité commerciale fournie aux clients. Ainsi, si vous pensez que le client n'aura souvent besoin que de la voiture, vous devez définir une opération qui ne renverra que la voiture. Si le client a parfois besoin d'une voiture et de ses conducteurs, vous devez définir une deuxième opération qui renverra la voiture et ses conducteurs.

Si votre service fonctionne principalement comme un CRUD de haut niveau, il peut être raisonnable de retourner au moins le premier niveau d'objets liés, mais encore une fois, ce n'est qu'une généralisation basée sur la fonctionnalité fournie. Une autre technique utile peut être les agrégats. Dans les agrégats, les entités liées n'ont pas de sens sans l'entité mère. Par exemple, la voiture et le conducteur ne sont pas des agrégats car le conducteur est une entité distincte. Mais Invoice et InvoiceLine sont des agrégats car vous ne pouvez pas définir InvoiceLine sans Invoice. Dans ce cas, il peut être utile de retourner la facture avec toutes les InvoiceLines. Encore une fois, ce n'est pas vrai dans toutes les situations. J'ai travaillé sur une application d'approbation où les utilisateurs étaient autorisés à voir et à approuver uniquement l'en-tête de la facture et les lignes de facture de leur centre de coûts. Ainsi, si la facture contient plus de 50 lignes de facture mais que l'utilisateur n'est autorisé à voir qu'une seule ligne, il n'y a aucune raison de les transférer toutes.

Pensez à la fonctionnalité fournie par votre service et la complexité nécessaire des objets transférés sera beaucoup plus claire.

Answer 2

J'ai fait quelques recherches sur Google et j'ai trouvé l'article suivant qui suggère de ne s'adresser qu'aux entités immédiatement liées à celle que le client a demandée. Pour tous les autres : Orienté service ou orienté objet