Réutilisation basée sur serveur - DLL, GAC ou REST?

Question

Nous avons une fonctionnalité utilisée par plusieurs applications différentes (clients) sur le même serveur. Il est préférable de la modéliser en tant que service, de disposer d’une base de données principale et qu’une seule version de la fonctionnalité et de la base de données sera utilisée à la fois.

Jusqu'à présent, nous avons utilisé la réutilisation de DLL simple, avec la fonctionnalité, son fichier de configuration et les dépendances déployées partout où il est utilisé. Étant donné que toutes les modifications doivent maintenant être effectuées à plusieurs endroits, cette méthode est pénible lors de la création de nouvelles versions de la fonctionnalité ou lorsque de nouveaux clients souhaitent l'utiliser.

Nous nous demandons s’il existe un meilleur moyen de le faire et avons proposé deux alternatives.

1. Placez la DLL (et les dépendances) dans le GAC. La question est alors de savoir comment configurer le composant. Comme les clients ne s'intéressent pas à la configuration, nous nous orientons vers le stockage du fichier de configuration dans un chemin codé en dur sur le serveur.

2. Publiez la fonctionnalité en tant que service interne (basé sur REST). Son accès peut être limité aux clients internes utilisant le pare-feu.

Comme nous le voyons, les avantages du n ° 1 semblent être la performance et peut-être la sécurité, alors que le n ° 2 peut être considéré comme plus simple à configurer.

Reste-t-il quelque chose d'important ici? Quelqu'un a-t-il déjà vécu une situation similaire et souhaite-t-il partager ses idées?

Answer 1

C’est un problème avec lequel j’ai beaucoup lutté et il n’ya vraiment pas de meilleure réponse que celle-là, alors ça dépend. Mon opinion personnelle est que vous devez rester à l'écart de l'option 1 pour deux raisons:

1. Si tous vos clients partagent un seul fichier binaire, tous vos clients devront être testés à chaque modification. Maintenant, je sais que dans votre cas exact, vous devrez peut-être le faire de toute façon, car nous pouvons supposer que vous modifieriez la base de données située derrière le composant.
2. Ne codez rien en dur. Vous pouvez stocker votre chemin de configuration dans une section AppSettings du fichier machine.config.

Comme pour l’option 2, une alternative serait d’utiliser WCF (en supposant que votre environnement puisse le prendre en charge). En utilisant WCF, vous pourriez alors utiliser un transport TCP en utilisant la sérilisation binaire (et il pourrait y avoir un transport en mémoire partagée). Ces deux solutions contribueraient à réduire l’écart de performance (bien que l’option 1 soit toujours supérieure à une approche basée sur les services).

En choisissant l'option 2, vous évitez également de refaire le test de tous les clients, car vous pouvez développer des tests automatisés pour vérifier que votre contrat n'est pas rompu. Cela vous permettra de publier en un seul endroit, d'exécuter des tests automatisés rapides et de savoir que vous ne cassez pas les clients.

Cela dit, vous pouvez réaliser la même chose en utilisant l'option 1 et un bon ensemble de tests unitaires, mais, selon mon expérience, l'option 2 sera plus facile à long terme.

L'option 2 vous permet également de faire évoluer le service à l'avenir si vous avez besoin de plus de puissance CPU.

Personnellement, je pense que l’option 1 est plus facile à configurer car vous n’aurez pas à configurer votre pare-feu, à gérer l’authentification, à configurer un service, etc. Il sera également plus facile de déboguer (la distribution d’une application introduit de nouvelles types de pannes, par exemple le site hébergeant votre service se bloque et vos clients commencent à avoir des pannes).

Une dernière suggestion consiste à utiliser un modèle de proxy / façade pour isoler vos clients de l'emplacement réel du service. Cela vous permettra de développer au fil du temps sans avoir à modifier le code client.

Answer 2

Comme Josh l’a déjà dit, malheureusement, la réponse à ce type de questions est souvent "cela dépend".

Je suis un grand fan du GAC, mais vous ne devriez y insérer que du code dont vous êtes sûr qu'il fonctionne (presque) parfaitement et qu'il n'a pas besoin d'être mis à jour très souvent. Tant qu'un morceau de code est "en cours de développement", publiez-le simplement avec chaque application qui l'utilise.

Answer 3

Je dirais que l’option 1 serait plus simple et plus facile, d’autant plus que vous devrez simplement passer plus de temps à limiter la disponibilité du REST. (jeu de mots voulu!)

Answer 4

Josh indique la WCF comme une option, et c’est sûrement ce que je ferais avec cela.

Ce problème est exactement ce que la SOA est censée résoudre!