Meilleure pratique pour un grand service WCF?

Question

Quelle est la meilleure pratique pour écrire un service wcf assez volumineux, contenant beaucoup de Contrats d'Opération et de Contrats de Données?

Comment pourrais-je séparer les domaines fonctionnels dans plusieurs contrats, serait-il préférable de créer un point final pour chaque domaine fonctionnel?

Est-il possible de garder la source pour les différentes parties d'intervalle, mais toujours utiliser un seul service pour tous?

Où puis-je obtenir de bonnes informations sur la façon de planifier les contrats, ce qu'il faut inclure, comment diviser ...?

Answer 1

Cela a été une grande question entourant les services depuis leur création. La SOA réussie est une architecture SOA planifiée dans la mesure où vous parlez. Cela dit, je me suis toujours penché davantage sur la division des services, mais en les utilisant de manière composite. C'est-à-dire, plusieurs points de terminaison lorsque vous avez plusieurs contrats, mais la plupart d'entre eux sont seulement consommés par quelques points de terminaison qui sont consommés par les appelants non-service. (Wow, qui était une bouchée, at-il encore un sens?)

De plus, je vous conseille d'avoir aussi peu de contrats que possible. Trop de contrats peuvent conduire à une mauvaise gestion. Une bonne conception de contrat aidera à limiter le nombre de points de terminaison et d'appels de service. Supprimer les concepts OO de la conception de contrat est un moyen de le faire. La conception de contrat est un sujet en soi, mais il suffit de dire que grâce à une bonne planification des contrats (à l'avance), il y a une bonne conception des services.

Maarten Mullender writes a great blog sur la conception WCF, et est un incontournable. Il y a également quelques grands livres de SOA/WCF émergeant aussi.

Quelques bons livres:

• Pro WCF: Practical Microsoft SOA Implementation
• Programming WCF

Answer 2

Cela a été utile pour moi, il vient du site idesign.net et il a été rédigé par Juval Lowy:

WCF Coding Standard

Answer 3

Je vais dire que j'ai utilisé des contrats WCF monolithiques, des contrats fonctionnels séparés (avec un maximum de dix méthodes selon les directives de Juval dans son livre), et j'ai aussi essayé une architecture de gestion de messages où un service a une seule méthode qui prend un message de base, et les gestionnaires qui «savent» comment déballer et traiter le message après qu'il traverse le fil.

Je suis un grand fan de ce dernier si vous avez .NET des deux côtés de la clôture. Oren a un screencast sur l'idée avec le code. Je ne sais pas quels sont vos besoins mais cela fonctionne pour moi.

http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx

Cela dit si vous êtes déjà en provenance de « je besoin d'un grand service WCF » va alors une méthode est probablement pas pour vous le couper. Si cela est vrai, les services WCF de programmation de Juval Lowy sont la norme que vous devez respecter dans votre conception.

Answer 4

J'ai un poste ici sur la façon dont les opérations individuelles devraient différer des opérations de code traditionnel:

http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

Vous devriez finir que les opérations pour les événements d'affaires réels. Si jamais vous vous arrêtez et pensez "Je dois activer la prise en charge des transactions sur mon service Web", cela signifie que vous n'avez pas conçu l'opération avec une portée suffisamment large. Vous ne devriez jamais avoir à activer le support des transactions de service Web.

Je recommande fortement le blog de Bill Poole pour les concepts SOA de plus haut niveau. Voici un message pour commencer:

http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html

Answer 5

Je sais que c'est un ancien poste mais je pense des services de la même manière que je pense des objets dans la programmation. Gardez-les à leur strict minimum pour ce qu'ils doivent faire. Bien sûr, ne pas aller à l'extrême, mais je prends mes décisions en fonction des entités de données.

Un service pour compte, un pour le produit, etc.

Je ne sais pas ce que tout le monde penserait que si ...