Pourquoi un développeur devrait-il utiliser des services Web au lieu de connexions directes à une base de données?
Je recherche une liste des "dix premiers" des 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 un service pro-web mais je perds l'argument. J'ai une compréhension de base des services WCF/Web, personne d'autre ne le fait. Nous pouvons faire ce que nous voulons, mais nous devons nous en tenir à ce que nous choisissons maintenant.
Voici ce que j'ai trouvé. Plus?
- Les services Web WCF peuvent, s'ils sont correctement configurés, être plus sécurisés.
- Les modifications de la base de données doivent uniquement être effectuées au niveau du service (fichier de configuration ou service de recompilation).
- Une fois installés et hébergés, les services Web sont plus faciles à consommer.
Sécurité. Vous n'accordez l'accès DB à personne, sauf aux utilisateurs 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 utilisateur/rôle côté DB.
Réduction de la charge DB. Le service Web peut mettre en cache les données qu'il a récupérées de la base de données.
Mise en commun des connexions à la base de données (hat/tip @Dogs).
Un service Web peut utiliser un petit pool de connexions DB ouvertes en permanence. Les aides de diverses manières:
Le pool de connexions DB est limité côté serveur de base de données.
l'ouverture d'une nouvelle connexion DB est TRÈS coûteuse (en particulier pour le serveur de base de données).
Capacité de tolérance aux pannes - le service peut basculer entre les sources de données primaires/DR sans que les détails du basculement soient mis en œuvre par les consommateurs de services.
Évolutivité - le service peut répartir les demandes entre plusieurs sources de données parallèles sans que les consommateurs de services mettent en œuvre les détails de la sélection des ressources.
Encapsulation. Vous pouvez modifier l'implémentation de base de données sous-jacente sans affecter les utilisateurs du service.
Enrichissement des données (cela comprend tout, de la personnalisation du client à la localisation à l'internalisation). Fondamentalement, tout cela peut être utile, mais l'un d'eux est une charge majeure sur la base de données et souvent très difficile à implémenter à l'intérieur d'une base de données.
Peut ou peut ne pas s'appliquer à vous - certaines décisions d'architecture ne sont pas compatibles avec l'accès DB. Par exemple. Java Les serveurs 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 peut-être pas) être.
Portabilité. Vos clients peuvent ne pas tous être sur la même plate-forme/architecture/langue. Recréer une bonne couche d'accès aux données dans chacun d'entre eux est plus difficile (car il doit prendre en compte des problèmes tels que les basculements mentionnés ci-dessus/etc ...) que de créer une couche grand public pour un service Web.
L'optimisation des performances. En supposant que l'alternative est 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. De plus, si le service Web limite l'ensemble des requêtes autorisées, il peut vous aider à optimiser considérablement votre base de données. Je dois ajouter que cette logique s'applique également aux procédures stockées, et pas uniquement aux services Web.
Une bonne liste peut également être trouvée sur cette page: 'Encapsuler l'accès à la base de données: une "meilleure" pratique agile'
Pour être 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.
À mon avis, vous ne devez 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 les services Web.
- Il n'y a aucune raison pour qu'une connexion à la base de données ne soit pas sécurisée
- Vous pouvez encapsuler la base de données dans une couche d'accès aux données (éventuellement Entity Framework)
- Les services Web ne sont pas plus faciles à utiliser qu'une couche d'accès aux données bien écrite.
- 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 par les services Web garantit que la logique d'application a la chance de s'exécuter, protégeant ainsi l'intégrité des données.
- Les services Web permettent de prendre les mesures d'authentification/autorisation les plus appropriées, par opposition à une base de données nécessitant un nom d'utilisateur et un mot de passe/privilèges de niveau 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 transit sur des réseaux non sécurisés. Je ne connais aucune solution de connexion DB directe qui permette cela ...?
La plupart de ces points s'appliquent à toute API formelle, pas spécifiquement aux services Web.
1) Les maux de tête liés à la maintenance de la base de données sont réduits du côté des développeurs afin qu'ils ne puissent se concentrer que sur le développement.
2) Le service Web prend en charge la communication de différentes plates-formes (systèmes d'exploitation tels que Windows, iOS, Android, etc.) d'une manière très simple et efficace. par exemple, considérons une situation où Android application & ios application veut communiquer avec un site Web qui est Java basé donc pour la communication des trois choses, le webservice est le meilleure solution au lieu de maintenir trois bases de données différentes.
L'écriture d'un service Web qui englobe simplement les appels aux procédures stockées semble être une approche erronée pour concevoir un bon DAL. Il est plus que probable que vos procédures stockées sont du code hérité d'un ancien système 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 impact sur les performances aux applications Web qui ont été "contraintes" à sortir avec ce "cochon". Je travaille actuellement sur un projet où notre nouveau L'application MVC-4 a été chargée d'utiliser un tel DAL. Nous avons le fardeau d'avoir à modifier à la fois la signature WebMethod et la signature SP chaque fois qu'une nouvelle user story survient nécessitant de telles modifications; ce qui pour nous, c'est chaque sprint. Inhérent à une telle approche passthru est deux niveaux étroitement couplés.
En général
- Le niveau de service Web favorise la réutilisation des demandes de données communes pour plusieurs applications
- Le service Web peut être configuré avec la 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 pour utiliser les sources de base de données existantes.
- 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 URI simple, ce qui signifie que les applications clientes peuvent être développées en utilisant une norme plus commune qui encourage des interfaces uniformes fiables.
Je commence tout juste à regarder ASP.NET Web Api et je prévois de créer des services de données en premier.
Je me suis récemment concentré sur les applications Web .NET MVC avec l'utilisation du framework d'entité.
- Si vous utilisez déjà MVC, Web Api utilise également MVC avec le contrôleur Api, de sorte que la courbe d'apprentissage pour créer les services est assez indolore.
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 plus tôt qui présentait un autre problème avec Visual Studio 2012 poussant une approche de fabrique de connexions plus moderne avec des assemblages 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 "plus 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 charge Assembly dll et j'ai pu travailler avec Oracle sans problème.
Certains services Web ont été créés et fonctionnaient avec des connexions à l'ancienne version d'Oracle. Ils ont été construits avec des méthodes qui ont été spécifiquement mappées sur des tables sélectionnées, mais à 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 allait écrire de nouvelles procédures stockées pour remplacer les anciennes que j'utilisais pour abstraire 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 d'une liste déroulante ou la saisie semi-automatique avec des données à l'échelle de l'entreprise soient effectuées via des services de données qui appellent les procédures stockées Oracle. Pourquoi répéter ce processus sur chaque application et que chaque développeur éprouve des difficultés avec la configuration et l'assemblage de version/charge, problèmes TNS?
alors....
- 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 peut généralement utiliser EF pour l'utilisation des données SQL Server, pourquoi ne pas pousser ces maux de tête jusqu'aux méthodes de service Web Api où ces problèmes de configuration peuvent être isolés.
- Encore une fois, l'interface client peut être effectuée en utilisant JavaScript, JQuery et JSON que vous utilisez déjà si vous le faites en utilisant Web Api pour effectuer des demandes de données SQL Server.
Je suis un développeur/analyste d'applications et non un administrateur de base de données, donc mon point de vue est celui de l'expérience avec la frustration sans fin d'avoir à modifier constamment les applications lorsque les outils de base de données évoluent.