J'utilise .NET 4 pour créer une petite application de serveur client pour un client. Devrais-je créer un service géant qui implémente de nombreux contrats (iinvoice, iParchase, IsalesOrder, etc.) ou devrais-je créer de nombreux services qui exécutent un contrat chacun sur de nombreux ports? Mes questions sont spécifiquement intéressées par les avantages / inconvénients de l'un ou l'autre choix. En outre, quel est le moyen courant de répondre à cette question?
Mon vrai dilemme est que je n'ai aucune expérience en faisant cette décision et j'ai peu d'expérience avec WCF que j'ai besoin d'aide pour comprendre les implications techniques d'une telle décision.
6 Réponses :
Son semble que vous mélangez entre Datacontract (s) et Servicecontract (s). Vous pouvez avoir un servicecontract et de nombreux Datacontract (s) et cela conviendrait parfaitement à vos besoins.
Dans les applications en temps réel, vous avez un contrat de service pour chaque entité comme facture, achat et vendeur aura des servicocontrices distincts
Toutefois, pour chaque contrat de service, des clients hétérogènes comme la facture seront appelés par BackOffice via Windows, l'application Windows à l'aide de NetNamedpipeBinding ou de NettCPLinding et la même demande clientèle doit appeler le service à l'aide de BasichttpLinding ou WshttpBindings. Fondamentalement, vous devez créer plusieurs points de terminaison pour chaque service.
Ne créez pas un service important qui implémente N-Nombre de contrats de service. Ces types de services sont faciles à créer, mais deviendront éventuellement des maux de tête de maintenance et ne seront pas bien échelonnés. De plus, vous obtiendrez toutes sortes de conflits de codes s'il existe un groupe de développement en concurrence pour les check-ins / check-outs.
Ne créez pas trop de services non plus. Évitez le piège de rendre vos services trop fins. Essayez de créer des services basés sur une fonctionnalité. Les méthodes exposées par ces services ne devraient pas être graines fine non plus. Vous ferez mieux d'avoir moins de méthodes qui font plus. Évitez de créer des fonctions similaires telles que GetUserByID (INT ID), GetUserByName (nom de chaîne) en créant un getUser (utilisateur userObject). Vous aurez moins de code, une maintenance plus facile et une meilleure découverte.
Enfin, vous n'aurez probablement pas besoin d'un seul port, peu importe ce que vous faites.
Mise à jour 12/2018 Drôle de la façon dont les choses ont changé depuis que j'ai écrit cela. Maintenant, avec le modèle de micro-services, je crée beaucoup de services avec des API de chatty :)
Si vous utilisez des fichiers de classe / interface partielle pour éviter de fusionner des conflits, qu'en est-il de l'argument "ne va pas bien échouer"? Qu'est-ce que cela signifie techniquement?
@ Baskolein ... Cela signifie que si vous avez trop emballé dans un contrat unique, il peut devenir un goulot d'étranglement de performance ainsi qu'un maux de tête d'entretien / extensibilité.
Merci de votre réponse, mais ma question était plus "pourquoi" pourrait-elle être une question de performance non "quoi" est une question de performance. Vous dites "goulot d'étranglement": j'ai compris que dans ISS / WCF, chaque demande Web est une nouvelle instance de service. Plusieurs demandes sur un seul meilleur service seraient toujours multiples, pas une instance qui leur servait tous. Donc pas de problème d'échelle. Est-ce que ce raisonnement n'est-ce pas?
@ Baskolein ... Si certaines méthodes sont plus intenses de ressources, les autres peuvent avoir une incidence négative sur les performances sur les autres et le service dans son ensemble. Lorsqu'il est pris en compte dans un service de service / site Web distinct, ce risque est facilement manipulé.
Vous devez prendre la décision basée sur la charge attendue, l'extensibilité requise et la perspective future. Comme vous l'avez écrit "Application de Small Client Server pour un client", il ne donne pas une idée précise de l'utilisation prévue du développement en main. La réponse de M. Big doit également être prise en compte.
Vous êtes le bienvenu de mettre en avant une question supplémentaire avec des données spécifiques ou des particularités sur la situation à la main. Merci.
Vous créeriez généralement des services différents pour chaque entité principale comme Iinvoice, IPTHECHASE, IsalalOrderOrder.
Une autre option consiste à séparer les requêtes des commandes. Vous pouvez avoir un service de commandement pour chaque entité principale et mettre en œuvre des opérations commerciales n'ayant accepter que les données dont elles ont besoin pour effectuer l'opération (éviter les opérations de type CRUD); et un service de requête qui renvoie les données dans le format requis par le client. Cela signifie que la partie de commande utilise le modèle de domaine / couche de domaine sous-jacent; Bien que le service de requête fonctionne directement sur la base de données (contourner l'entreprise, qui n'est pas nécessaire pour interroger). Cela simplifie beaucoup votre interrogation et le rend plus flexible (ne renvoie que ce que les besoins du client).
La vérité est que la scission des services de WCF - ou tout service est un acte d'équilibre. Le principe est que vous souhaitez maintenir la pression à la baisse sur la complexité tout en considérant la performance.
Plus les services que vous créez, plus vous devrez écrire une configuration. En outre, vous augmenterez le nombre de classes de proxy dont vous avez besoin pour créer et entretenir du côté du client. P>
Mettre trop de servicocontracts sur un seul service augmentera le temps nécessaire pour générer et utiliser un proxy. Mais, si vous ne vous retrouvez que sur une ou deux opérations sur un contrat, vous aurez une complexité supplémentaire au système avec très peu à gagner. Ce n'est pas une ordonnance scientifique, mais une bonne règle de fonctionnement pourrait dire environ 10-20 fonctionnalités par serviceecontract. P>
Couplage de classe est bien sûr une considération, mais faites-vous vraiment affaire avec des préoccupations distinctes? Cela dépend de ce que votre système fait, mais la plupart des systèmes ne traitent que de quelques domaines de préoccupation, de sorte que les choses qui se séparent peuvent ne pas diminuer les couples de classe qui de toute façon. P>
Une autre chose à retenir, et c'est ultra important est de toujours rendre vos méthodes aussi génériques que possible. WCF traite des données Datacontractes pour une raison. Datacontract signifie que vous pouvez envoyer n'importe quel objet au serveur et à partir du serveur tant que les données de données sont connues. P>
Donc, par exemple, vous pourriez avoir 3 fonctionnalités de fonctionnement: P>
[OperationContract] IDatabaseRecord GetDatabaseRecord(string recordTypeName, string id);