Je construis un ensemble de méthodes pour fournir une fonctionnalité à un certain nombre d'applications Web différentes, les méthodes obtiennent essentiellement des données de SQL d'effectuer des opérations à ce sujet, puis de la transmettre à l'application d'appel. Ils doivent être mis en œuvre via des services Web.
Donc, ma question est de savoir quels sont les avantages et les inconvénients entre créer un service Web massif avec de nombreuses méthodes ou diviser les méthodes en groupes logiques et englobant chacun d'entre eux dans leur propre service Web. Je pense qu'il y aura beaucoup de méthodes ultérieures mises en œuvre après la première version de sorte que tout ce que je fais doit être facilement maintenu.
S'il a un impact sur les réponses que j'utilise .NET 3.5, C # et ne peut pas utiliser WCF pour le moment.
4 Réponses :
Nous avons dû prendre la même décision il y a plusieurs années. Nous sommes allés avec l'approche très granulaire. Cela nous a très bien servi. Cela nous a permis de révéler les webservices dans une API de TRES. Ce n'était pas notre intention d'origine, mais cela a très bien fonctionné pour nous.
Randy
un gros contre:
lotsa petits plus facile à entretenir. Un changement dans une signature est un petit changement pour les clients.
plus facile à utiliser différents hôtes.
contre:
Mon conseil est de regarder les forfaits logiques de vos services. Les clients sont-ils susceptibles d'utiliser une partie de vos services, ou tous? Y a-t-il des cas où ils devront utiliser la moitié des services n ° 1 et la moitié du service n ° 2? Essayez de comprendre ce que sont les scénarios communs et concevez vos services afin qu'ils ne nécessitent que créer un proxy pour le travail.
Avantages:
Avantages:
Comme Randy Minder, nous avons mis en place de nombreux services plus petits qui avaient des rôles très distincts dans l'application globale. Nous avons rencontré les scénarios exacts que vous avez décrits: nous pourrions les maintenir tous facilement et indépendamment, mais les emballage et les mettre à la disposition de tous les uns avec les autres était un problème. Il y avait beaucoup d'abus de copie / colle pour obtenir des fonctions communes telles que la lecture de valeurs de configuration, mais nous travaillons activement à l'isolement à une assemblée partagée. Je pense toujours que c'était la bonne approche.
Maintenant que Docker ou Rocket sont ici, il semble qu'ils puissent fournir les outils nécessaires pour éviter le désordre de configuration résultant de la fragmentation des services. Vérifiez également Docker-Compose.
L'avantage de les diviser dans des services distincts est que si vous commencez à courir dans des problèmes de performances, vous pouvez toujours déplacer des services individuels sur des serveurs distincts.
L'avantage de les garder ensemble dans un grand service est que certains code (par exemple, les informations de configuration de la lecture d'un fichier) seront identiques à tous les services et vous pouvez réutiliser le code si c'est tout dans un seul service. (Vous pouvez également mettre votre code réutilisé dans une bibliothèque de classe distincte).
Vous pouvez faire des arguments pour les deux cas. Les deux plus grandes questions que j'aurais sont: 1) Les services sont-ils liés? Cela a-t-il logique de les regrouper ensemble ou de les regrouper ensemble pour plus de commodité? S'ils sont liés, cela pourrait être logique de les garder ensemble.
2) Quel type de charge attendez-vous? Pouvez-vous vous attendre de manière réaliste à un serveur de gérer la charge de tous les services pour les prochaines années? Sinon, il serait peut-être préférable de les séparer maintenant.
Je ne pense pas que la charge va être un problème pour nous dans ce système particulier, mais un bon point grâce.
Un peu de nourriture pour la pensée: granulaire est bon pour plus de contrôle, mais il a une pénalité de performance associée. Si vous allez trop granuleux, vous risquez de vous retrouver avec une API qui nécessiterait plusieurs voyages ronds de réseau pour faire tout ce qui est non trivial. Donc, je voudrais garder le réseau aller-retour et la latence à l'esprit lors de la conception du service. Si le service doit être potentiellement situé sur un réseau étendu, je m'abstiendrais de faire une interface "chaty" et d'aller pour des méthodes qui renvoient plus de données.
comme par exemple, préférez récupérer un utilisateur entier plus leur historique de commande, au lieu d'un appel distinct pour les données de l'utilisateur et un autre appel distinct pour l'historique de la commande si la plupart du temps de l'utilisateur et L'historique des commandes sera obligatoire à la fois par l'appelant. Vous devez déterminer comment le service va être utilisé et factoriez vos interfaces en conséquence.
Si vous recherchez un terme pour décrire l'expansion désorganisée des offres de Webservice au fil du temps: Shawn Wildermuth fait référence à la "pollution de la méthode" dans l'épisode # 497 de .NET ROCKS (voir page 17 de la transcription @ goo.gl/jyen ).
Merci Lance je vais vérifier cela.