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

Question

Je suis à la recherche d'un "top ten" liste de raisons pour lesquelles nous devrions être en connexion à distance des bases de données via des web services au lieu de se connecter directement à la base de données. C'est un débat interne, et je suis pro-web service mais la perte de l'argument. J'ai une connaissance de base de la WCF / web services, personne d'autre ne le fait. Nous pouvons faire ce que nous voulons aller de l'avant, mais nous avons besoin de coller avec ce que nous choisissons.

Voici ce que j'ai trouvé. Plus?

1. Les services web WCF peut, s'il est configuré correctement, être plus sûr.
2. Les changements à la base de données ne doivent être effectués au niveau du service (fichier de config ou de recompiler service).
3. Une fois l'installation et les hébergés, les services web sont plus faciles à consommer.

Answer 1

1. De sécurité. Vous n'êtes pas à l'octroi DB accès à n'importe qui mais de du serveur web/application utilisateur.

   Ceci est très important lorsque vous avez des tonnes d'utilisateurs. Vous éviter la douleur de l'utilisateur/rôle de la maintenance sur DB côté.

2. DB de réduction de la charge. Service Web peut mettre en cache les données récupérées à partir de DB.

3. Capacité pour la tolérance aux pannes - le service peut basculer entre le primaire/DR sources de données, sans avoir les détails de basculement être mis en œuvre par le service consommateurs.

4. Évolutivité - le service de la propagation des requêtes entre plusieurs parallèle des sources de données sans avoir les détails de la ressource cueillette être mis en œuvre par le service consommateurs.

5. L'Encapsulation. Vous pouvez changer les sous-jacents DB mise en œuvre sans impact sur les utilisateurs du service.

6. Enrichissement des données (ce qui comprend quelque chose à partir d'un client de personnalisation de la localisation d'internalisation). Fondamentalement, l'un de ces pourrait être utile, mais l'un d'eux est une charge importante sur la base de données et souvent très difficile à mettre en œuvre à l'intérieur d'une DB.

7. Peut ou peut ne pas s'appliquer à vous - certaines décisions relatives à l'architecture ne sont pas DB acces convivial. E. g. Java Serveurs sous Unix ont un accès facile à une base de données, alors qu'un client java en cours d'exécution sur un PC Windows n'est pas conscient de la base de données et que vous n'avez peut-être voulez qu'il soit.

8. La portabilité. Vos clients ne peuvent pas tous être sur la même plate-forme/architecture/langue. Re-création d'une bonne couche d'accès aux données dans chacune de celles-ci est plus difficile (car il doit prendre en compte des questions telles que mentionnés ci-dessus basculements/etc...) que la construction d'un consommateur couche pour un service web.

9. L'optimisation des performances. En supposant que l'alternative est les clients qui exécutent leurs propres requêtes (et non pas pré-conserves de procédures stockées), vous pouvez être sûr à 100% qu'ils vont commencer à utiliser moins qu'optimale des requêtes. Aussi, si le service web limites de l'ensemble admissible de requêtes, il peut aider avec votre paramétrage des bases de données de manière significative. Je dois ajouter que cette logique s'applique également aux procédures stockées, n'est pas unique à des services web.

Une bonne liste peut également être trouvé sur cette page: 'Encapsulation d'Accès de Base de données: Un Agile "Meilleure Pratique"'

Juste pour être au clair - certaines de ces questions peuvent ne pas être applicables à TOUTES les situations. Certaines personnes ne se soucient pas de la portabilité. Certaines personnes n'ont pas besoin de s'inquiéter au sujet de DB de sécurité. Certaines personnes n'ont pas besoin de s'inquiéter au sujet de DB évolutivité.

Answer 2

À 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 nécessairement s'effectuer via des services Web.

1. Il n'y a aucune raison pour qu'une connexion à une base de données ne soit pas 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 à consommer qu'une couche d'accès aux données bien écrite.

Answer 3

• Services Web forme d'une API, de définir les permis des interactions entre les systèmes et les données de l'application.
• Les Services Web de découpler la base de données à partir d'interactions externes et l'activation de la couche de données pour être gérés indépendamment de ces influences extérieures.
• Permettant l'accès uniquement par le biais de Web Services permet à la logique de l'application a la chance d'exécuter, de la protection de l'intégrité des données.
• Les Services Web permettent le plus approprié d'authentification/autorisation de prendre des mesures, par opposition à une base de données nécessitant un nom d'utilisateur et un mot de passe/niveau de la table des privilèges.
• Les Services Web fournissent une occasion pour le service de découverte automatique et la configuration à utiliser.
• Le trafic des Services Web peuvent être chiffrées à des fins de transit sur les réseaux non sécurisés. Ne sais pas du tout direct DB connexion à des solutions qui permettent que...?

La plupart de ces points pour l'une formelle de l'API qui n'est pas spécifiquement des Services Web.

Answer 4

La rédaction d'un service web qui encapsule simplement des appels de procédures stockées semble être une mauvaise approche pour la conception d'un bon DAL. Plus que probablement, vos procédures stockées sont code héritage laissé par un ancien client-serveur systèmes d'affaires les règles sont enterrés dans le domaine SPs. Si c'est le cas, vous êtes vraiment de tenter la création d'une bourse de soie d'une oreille de truie.

En outre, l'ajout d'un message SOAP protocole de couche qui ajoute un gain de performance pour des applications web qui ont été "contraints" à la datation de cette 'cochon'. Je travaille sur un projet en ce moment où notre nouveau MVC-4 application a été invité à utiliser un DAL. Nous avons la charge d'avoir à changer à la fois la WebMethod signature et le SP signature à chaque fois qu'un nouvel utilisateur histoire vient nécessitant de tels changements, ce qui pour nous, est que chaque sprint. Inhérents à un tel genre de démarche est de deux étroitement couplé niveaux.

Answer 5

En général

1. Web de niveau de Service favorise la réutilisation de la commune de demandes de données pour des applications multiples
2. Service Web peut être mis en place avec gestion de version qui dévie de nombreuses questions découlant de l'application du niveau de développement. Par exemple, si je suis de nouveau à un projet existant de l'application dois-je utiliser comme un bon modèle pour la configuration de mon application à utiliser les sources de base de données.
3. Service Web a évolué pour permettre la flexibilité des options pour l'envoi de requêtes et obtenir des résultats de réponse de retour dans un format commun, tels que JSON à l'aide d'une URI qui signifie que les applications client peuvent être développées à l'aide d'une norme commune qui encourage fiable des interfaces uniformes.

Je suis juste en train de le fixaient avec ASP.NET l'Api Web et le plan sur les données des services de première.

J'ai récemment été en se concentrant sur .NET MVC applications web avec l'utilisation d'entity framework.

1. Si vous utilisez déjà MVC, Web Api utilise également MVC avec l'Api contrôleur de sorte que la courbe d'apprentissage pour construire les services sont assez indolore.

J'ai récemment trouvé moi-même dans une situation frustrante avec un MVC web app que j'ai été la construction à l'origine basé sur des procédures stockées Oracle. La version originale comme Oracle 9 ou même plus tôt, qui a présenté un autre problème avec Visual Studio 2012 en poussant un plus moderne usine de raccordement approche avec des temps de chargement des assemblages de trouver la bonne dll fichiers à utiliser basé sur le web de config des connexions et des noms TNS.

Les tentatives de connexion à la base de données a échoué avec l' "n'est plus pris en charge' des messages d'erreur. Par curiosité, j'ai téléchargé Oracle 12c et fait une demande au niveau des connexions qui fonctionnait très bien avec mon TNS noms et la charge de l'assemblée dll et j'ai pu travailler avec Oracle sans problème.

Il y avait quelques services web intégré qui travaillaient avec des connexions à l'ancienne version Oracle. Ils ont été construits avec des méthodes qui ont été spécifiquement mappés à des tables sélectionnées cependant à ma déception. Je dois écrire mon propre.

On m'a dit que le groupe qui était responsable du maintien de l'Oracle bases de données qu'ils seraient de l'écriture de nouvelles procédures stockées pour remplacer les plus anciens que j'ai été en utilisant l'abstraction de l'interface du client et de couches de logique métier.

Donc, mes premières pensées ont été que toutes les données communs tels que des demandes de remplissage dans la liste déroulante ou automatique complète avec l'entreprise les données à l'échelle du être fait par le biais de services de données qui permettrait d'attirer les procédures stockées Oracle. Pourquoi répéter ce processus sur chaque application et chaque développeur lutte avec la configuration et la version du/de la charge de l'assemblée, TNS questions?

donc....

1. Pour plusieurs serveur de base de données des questions telles que l'utilisation de procédures stockées Oracle dans un .NET MVC de l'application qui pourrait être généralement à l'aide de EF pour SQL Server à l'utilisation de données, pourquoi ne pas pousser ces maux de tête jusqu'à l'Api Web service méthodes où ces problèmes de configuration peuvent être isolés.
2. De nouveau le client interfaçage peut être fait à l'aide de JavaScript, JQuery et JSON qui vous sont déjà en utilisant si vous le faites à l'aide de l'Api Web pour faire de SQL Server demandes de données.

Je suis un Développeur d'Applications/Analyste et non pas un DBA donc mon point de vue est l'un avec l'expérience de la frustration sans fin d'avoir à constamment modifier les applications de base de données outils d'évoluer.