Je pense que vous confondez la responsabilité unique avec la ségrégation de l'interface. Du point de vue de l'interface client/service, vous devriez garder vos contrats allégés et mesquins. Voir ci-dessous pour un exemple de cela. Du côté de la SRP, cela devrait être entièrement interne à l'implémentation du service et le client ne devrait pas être conscient de cela. Si votre code de service est trop grand, divisez-le en classes. Ensuite, ayez votre code de service, au moins initialement, agir comme une façade et transmettre tous les appels aux objets pertinents. Plus tard, vous avez la possibilité de scinder votre service en plusieurs services. Mais sachez que SOA et la conception orientée objet, bien que se chevauchant, sont séparés et ont des exigences différentes.
Exemple de ségrégation d'interface: Nous avons ici un service que nous utilisons pour effectuer diverses fonctions sur certains objets métier. Le service d'origine avait une interface. Au fur et à mesure de son développement, nous avons réalisé que nous avions trois familles de méthodes: la persistance des objets de données, les mises à jour métier, l'analyse métier. Nous nous divisons en trois contrats. Notre client/service implémente tous les 3, donc la seule chose que nous devions faire était de scinder le contrat en trois et d'installer deux endpoints supplémentaires dans notre configuration WCF. Très simple.
Espérons que cela aide.
Je m'interroge à ce sujet aussi! Je ne fais que planifier les contrats de service de la WCF, et puisque chaque contrat devrait être petit et être responsable d'une unité de travail contenue, je pourrais me retrouver avec des centaines de contrats. Cela ne peut pas être le point, peut-il? – Sam