Pourquoi un développeur devrait-il utiliser des services Web au lieu de connexions directes à une base de données? [fermé]

93

Je suis à la recherche d'une liste des «dix principales» raisons pour lesquelles nous devrions nous connecter à des bases de données distantes via un service Web au lieu de nous connecter directement à la base de données. C'est un débat interne en ce moment et je suis pro-web service mais je perds l'argument. J'ai une connaissance de base des services WCF / Web, personne d'autre ne le fait. Nous pouvons faire tout ce que nous voulons pour aller de l'avant, mais nous devons nous en tenir à ce que nous choisissons maintenant.

Voici ce que j'ai trouvé. Plus?

  1. Les services Web WCF peuvent, s'ils sont configurés correctement, être plus sécurisés.
  2. Les modifications apportées à la base de données ne doivent être effectuées qu'au niveau du service (fichier de configuration ou service de recompilation).
  3. Une fois installés et hébergés, les services Web sont plus faciles à utiliser.
wcf web-services DenaliHardtail
la source

Réponses:

120

  1. Sécurité. Vous n'accordez l'accès à la base de données à personne, sauf à l'utilisateur du serveur Web / de l'application.

    Ceci est très important lorsque vous avez des tonnes d'utilisateurs. Vous évitez la douleur de la maintenance des utilisateurs / rôles côté DB.

  2. Réduction de la charge DB. Le service Web peut mettre en cache les données qu'il a extraites de la base de données.

  3. Regroupement des connexions à la base de données (hat / tip @Dogs).

    Un service Web peut utiliser un petit pool de connexions DB ouvertes en permanence. L'aide de différentes manières:

    • Le pool de connexion DB est limité côté serveur de base de données.

    • l'ouverture d'une nouvelle connexion à la base de données est TRÈS coûteuse (en particulier au serveur de base de données).

  4. Capacité de tolérance aux pannes - le service peut basculer entre les sources de données principales / DR sans que les détails du basculement soient mis en œuvre par les consommateurs de services.

  5. Évolutivité - le service peut répartir les demandes entre plusieurs sources de données parallèles sans que les détails de la sélection des ressources soient mis en œuvre par les consommateurs de services.

  6. Encapsulation. Vous pouvez modifier l'implémentation de base de données sous-jacente sans affecter les utilisateurs du service.

  7. L'enrichissement des données (cela comprend tout, de la personnalisation du client à la localisation en passant par l'internalisation). En gros, n'importe lequel de ces éléments peut être utile, mais n'importe lequel d'entre eux représente une charge majeure sur la base de données et est souvent très difficile à implémenter dans une base de données.

  8. Peut s'appliquer ou non à vous - certaines décisions d'architecture ne sont pas compatibles avec l'accès à la base de données. Par exemple, les serveurs Java fonctionnant sous Unix ont un accès facile à une base de données, alors qu'un client Java fonctionnant sur un PC Windows ne connaît pas la base de données et vous ne le souhaitez pas.

  9. Portabilité. Vos clients peuvent ne pas tous être sur la même plateforme / architecture / langue. Recréer une bonne couche d'accès aux données dans chacun de ceux-ci est plus difficile (car cela doit prendre en compte des problèmes tels que les basculements mentionnés ci-dessus / etc ...) que de créer une couche consommateur pour un service Web.

  10. L'optimisation des performances. En supposant que l'alternative soit que les clients exécutent leurs propres requêtes (et non des procédures stockées prédéfinies), vous pouvez être sûr à 100% qu'ils commenceront à utiliser des requêtes moins qu'optimales. En outre, si le service Web limite l'ensemble des requêtes autorisées, il peut vous aider considérablement à régler votre base de données. Je dois ajouter que cette logique est également applicable aux procédures stockées, pas uniquement aux services Web.

Une bonne liste peut également être trouvée sur cette page: 'Encapsulation de l'accès aux bases de données: une "meilleure" pratique Agile "

Pour être parfaitement clair, certains de ces problèmes peuvent ne pas s'appliquer à TOUTES les situations. Certaines personnes ne se soucient pas de la portabilité. Certaines personnes n'ont pas à se soucier de la sécurité de la base de données. Certaines personnes n'ont pas à se soucier de l'évolutivité de la base de données.

DVK
la source
26
Désolé, pas d'accord. 1. Vous accordez donc l'accès à la base de données à un groupe au lieu d'un seul mandant - aucune différence. 2. N'importe quelle application peut mettre en cache des données. Le type de données qui peut être mis en cache sur plusieurs utilisateurs sera généralement des données de faible volume dans tous les cas. 3. Le FT devrait être géré par la base de données dans tous les cas. 4. Ce n'est pas une fonction prête à l'emploi et doit être programmé. 5. Votre couche d'accès aux données doit effectuer l'encapsulation. 6. Même chose. 7. Vraiment? JDBC ne fonctionne pas dans un client? 8. Bon point, quand ça compte, ce qui est rare. 9. La requête contre SP ne faisait pas partie de la question.
John Saunders
7
1. Essayez de gérer cela sur 5 000 utilisateurs avec des centaines de rôles. Ne s'adapte plus aussi bien. 2. Dépend entièrement d'une application. Notre cas actuel contient une instance de mise en cache des résultats d'une requête qui, dans un cas ultra-optimisé, prend 20 minutes à exécuter et dont nous avons besoin pour exécuter des centaines de fois par jour au moins à partir de différentes applications. 3. Le FT est géré à plusieurs niveaux. Que voulez-vous dire "devrait être géré par une base de données"?
DVK
4
4. Bien sûr, il doit être programmé. Mais il peut être programmé dans le service une fois, ou dans un zillion d'applications clientes sur diverses plates-formes avec des capacités variables. Il y a une différence majeure. Peu importe les problèmes de gestion de la configuration pour l'équilibrage de charge. 5. Même raisonnement. Vous n'avez pas besoin de réimplémenter DAL. En fait, vous pouvez simplement considérer le service Web comme un DAL portable pour vous détendre. 7. Nous ne voulons pas que chaque client ouvre des connexions DB. Est-ce une si grande chose à demander? Encore une fois, vous oubliez les points 1 à 5.
DVK
2
8.> 1 architecture client arrive TRÈS souvent. En fait, je n'ai jamais travaillé sur un projet sans une telle situation dans ma vie, mais je suis centré sur le monde financier. 9. Ce n'était pas le cas. Je jouais essentiellement l'avocat du diable.
DVK
2
J'aime cette réponse, mais je pense que vous avez sauté l'un des points les plus importants: le regroupement de connexions. Si vous avez 1 000 000 de clients, vous aurez soit 1 000 000 de connexions ouvertes, soit des millions de connexions constamment ouvertes et fermées. L'intuition de base sur l'organisation informatique nous dit qu'un pool bien réglé de quelques centaines de connexions à longue durée de vie est astronomiquement plus efficace qu'un million de connexions à longue durée de vie ou des millions de connexions de courte durée. Le HikariCP fait un excellent travail d'élaboration de cette idée: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Dogs
15

À mon avis, vous ne devriez pas exposer automatiquement votre base de données en tant que service Web. S'il s'avère que vous avez besoin d'un service pour exposer vos données, écrivez-en un, mais tous les accès à la base de données ne doivent pas être effectués via des services Web.

  1. Il n'y a aucune raison pour laquelle une connexion à une base de données ne devrait pas être sécurisée
  2. Vous pouvez encapsuler la base de données dans une couche d'accès aux données (éventuellement Entity Framework)
  3. Les services Web ne sont pas plus faciles à utiliser qu'une couche d'accès aux données bien écrite.
John Saunders
la source
Pourquoi forcément XML? Il y a aussi beaucoup plus de facilité à analyser JSON, CSV pour des données simples, etc.
DVK
Ce n'est pas «sans raison». Comme indiqué à propos de, en fonction de vos besoins et de vos désirs de développement futur, cela peut être nécessaire pour votre projet.
Chris Stewart
J'écris mon WS pour consommer un DAL. Sur quel port suggéreriez-vous d'exposer un DAL?
samis
@samus ça n'a pas d'importance.
John Saunders
"Il n'y a aucune raison pour qu'une connexion à une base de données ne soit pas sécurisée", eh bien, il est difficile par exemple de sécuriser la connexion entre un client Windows et une base de données. Vraiment difficile de mettre en place une connexion sécurisée!
NoChance
12
  • Les services Web forment une API, définissant les interactions autorisées entre les systèmes externes et les données de l'application.
  • Les services Web dissocient la base de données des interactions externes et permettent de gérer la couche de données indépendamment de ces influences extérieures.
  • Autoriser l'accès uniquement aux services Web garantit que la logique d'application a la possibilité de s'exécuter, protégeant ainsi l'intégrité des données.
  • Les services Web permettent de prendre les mesures d'authentification / d'autorisation les plus appropriées, par opposition à une base de données nécessitant un nom d'utilisateur et un mot de passe / des privilèges au niveau de la table.
  • Les services Web offrent la possibilité d'utiliser la découverte et la configuration automatiques des services.
  • Le trafic des services Web peut être chiffré pour le transit sur des réseaux non sécurisés. Vous ne connaissez aucune solution de connexion directe à la base de données qui permet cela ...?

La plupart de ces points concernent toute API formelle, pas spécifiquement les services Web.

brabster
la source
1
Oui, c'est ce que j'allais dire, si vous avez une seule application accédant à une base de données, tous vos points sont également disponibles pour les API normales.
Ignacio Soler Garcia
"Les services Web forment une API, définissant les interactions autorisées entre les systèmes externes et les données de l'application." Vous pouvez également le faire avec une base de données.
Chaussure du
"Autoriser l'accès uniquement aux services Web garantit que la logique d'application a la possibilité de s'exécuter, protégeant ainsi l'intégrité des données." - Je dirais que l'intégrité des données devrait faire partie du SGBD uniquement.
Chaussure du
@Shoe C'est bien d'imposer autant d'intégrité que possible par la base de données, mais à mesure que les données commencent à se remplir et à exposer des lacunes, comme la nécessité d'une validation d'entrée, il est agréable de l'appliquer au niveau de l'application (même si je préfère appliquer sur le côté client, il doit parfois être traité côté serveur si les règles de validation dépendent de données connues uniquement du serveur (conservées depuis l'application cliente)). Est-ce un gros problème de changer l'ensemble de règles d'intégrité d'une base de données, j'imagine que ce n'est pas une question triviale?
samis
2

L'écriture d'un service Web qui encapsule simplement les appels à des procédures stockées semble être une approche erronée pour concevoir une bonne DAL. Plus que probablement, vos procédures stockées sont du code hérité laissé par d'anciens systèmes client-serveur, c'est-à-dire que les règles métier sont enfouies dans les SP. Si tel est le cas, vous essayez vraiment de créer un sac à main en soie à partir de l'oreille d'une truie.

De plus, vous ajoutez une couche de protocole de message SOAP qui ajoute un coup de performance aux applications Web qui ont été `` contraintes '' à sortir avec ce `` cochon ''. Je travaille actuellement sur un projet où notre nouvelle application MVC-4 a été chargée d'utiliser un tel DAL. Nous avons le fardeau de devoir changer à la fois la signature WebMethod et la signature SP chaque fois qu'une nouvelle user story survient et nécessite de tels changements; ce qui pour nous, c'est chaque sprint. Une telle approche de relais est inhérente à deux niveaux étroitement couplés.

Sevasanakid
la source
1
L'API Web a résolu le problème de ballonnement WCF / SOAP. C'est maintenant comme un félin léger, en forme et agile; exactement ce dont il a besoin pour servir en REST.
samis
En théorie, il n'est pas faux d'appeler des processus stockés à l'aide de services Web.
NoChance
2

1) Le mal de tête lié à la maintenance de la base de données est réduit du côté des développeurs afin qu'ils puissent se concentrer uniquement sur le développement.

2) Le service Web prend en charge la communication de différentes plates-formes (systèmes d'exploitation comme Windows, iOS, Android, etc.) dans une méthode très simple et efficace. par exemple, considérons une situation où une application Android et une application ios veulent communiquer avec un site Web basé sur Java, de sorte que pour la communication des trois choses, le service Web est la meilleure solution au lieu de maintenir trois bases de données différentes.

Rohan
la source
1

En général

  1. Le niveau de service Web favorise la réutilisation des demandes de données courantes pour plusieurs applications
  2. Le service Web peut être configuré avec une gestion des versions qui évite de nombreux problèmes liés au développement au niveau de l'application. Par exemple, si je suis nouveau dans un projet, quelle application existante dois-je utiliser comme bon modèle pour configurer mon application afin d'utiliser les sources de base de données existantes.
  3. Le service Web a évolué pour permettre des options flexibles pour envoyer des demandes et obtenir des résultats de réponse dans un format commun tel que JSON en utilisant un simple URI, ce qui signifie que les applications clientes peuvent être développées à l'aide d'une norme plus courante qui encourage des interfaces uniformes fiables.

Je suis juste en train de commencer avec ASP.NET Web Api et je prévois de créer d'abord des services de données.

Je me suis récemment concentré sur les applications Web .NET MVC avec l'utilisation du framework d'entité.

  1. Si vous utilisez déjà MVC, l'API Web utilise également MVC avec le contrôleur Api, de sorte que la courbe d'apprentissage pour créer les services est assez simple.

Je me suis récemment retrouvé dans une situation frustrante avec une application Web MVC que je construisais à l'origine sur la base de procédures stockées Oracle. La version originale comme Oracle 9 ou même antérieure qui présentait un autre problème avec Visual Studio 2012 poussant une approche de fabrique de connexions plus moderne avec des assemblys de temps de chargement trouvant les bons fichiers dll à utiliser en fonction des connexions de configuration Web et des noms TNS.

Les tentatives de connexion à la base de données ont échoué avec des messages d'erreur «non pris en charge». Par curiosité, j'ai téléchargé Oracle 12c et établi des connexions au niveau de l'application qui fonctionnaient bien avec mes noms TNS et la DLL d'assemblage de charge et j'ai pu travailler avec Oracle sans problème.

Certains services Web créés fonctionnaient avec des connexions à l'ancienne version d'Oracle. Ils ont été construits avec des méthodes spécifiquement mappées sur des tables sélectionnées, à ma grande déception. Je devrais écrire le mien.

On m'a dit que le groupe responsable de la maintenance des bases de données Oracle écrirait de nouvelles procédures stockées pour remplacer les anciennes que j'utilisais pour résumer l'interface client et les couches de logique métier.

Donc, mes premières réflexions ont été que toutes les demandes de données courantes telles que le remplissage de la liste déroulante ou l'auto-complétion avec des données à l'échelle de l'entreprise soient effectuées via des services de données qui appelleraient les procédures stockées Oracle. Pourquoi répéter ce processus sur chaque application et que chaque développeur se débat avec la configuration et l'assemblage de version / charge, les problèmes de TNS?

alors....

  1. Pour plusieurs problèmes de serveur de base de données, tels que l'utilisation de procédures stockées Oracle dans une application .NET MVC qui pourrait généralement utiliser EF pour l'utilisation des données SQL Server, pourquoi ne pas transmettre ces maux de tête aux méthodes de service Web Api où ces problèmes de configuration peuvent être isolés.
  2. Encore une fois, l'interfaçage client peut être effectué à l'aide de JavaScript, JQuery et JSON que vous utilisez déjà si vous le faites à l'aide de Web Api pour effectuer des demandes de données SQL Server.

Je suis un développeur / analyste d'applications et non un DBA, donc mon point de vue est basé sur l'expérience avec la frustration sans fin de devoir constamment modifier les applications lorsque les outils de base de données évoluent.

Brian Quinn
la source