Why should a developer use web services instead of direct connections to a db?

I'm looking for a "top ten" list of reasons why we should be connecting to remote databases via web service instead of directly connecting to the db. This is an internal debate right now and I'm pro-web service but losing the argument. I have a basic grasp of WCF / web services, no one else does. We can do whatever we want moving forward but we need to stick with whatever we choose now.

Here is what I've come up with. Any more?

1. WCF web services can, if configured correctly, be more secure.
2. Changes to the DB only need to be made at the service level (config file or recompile service).
3. Once setup and hosted, web services are easier to consume.

1. Security. You're not granting DB access to anyone but web server/app user.

   This is extra important when you have tons of users. You avoid the pain of user/role maintenance on DB side.

2. DB load reduction. Web service can cache the data it retrieved from DB.

3. Database connection pooling (hat/tip @Dogs).

   A web service can use a small pool of permanently opened DB connections. The helps in a variety of ways:

   • DB connection pool is limited on database server side.

   • opening a new DB connection is VERY costly (especially to database server).

4. Ability for fault tolerance - the service can switch between primary/DR data sources without having details of fail-over be implemented by service consumers.

5. Scalability - the service can spread requests between several parallel data sources without having details of the resource picking be implemented by service consumers.

6. Encapsulation. You can change underlying DB implementation without impacting service users.

7. Data enrichment (this includes anything from client customization to localization to internalization). Basically any of these might be useful but any of them is a major load on database and often very hard to implement inside a DB.

8. May or may not apply to you - certain architecture decisions are not DB acces friendly. E.g. Java Servers running on Unix have an easy access to a database, whereas a java client running on a Windows PC is not database aware nor do you possibly want it to be.

9. Portability. Your clients may not all be on the same platform/architecture/language. Re-creating a good data access layer in each one of those is harder (since it must take into account such issues as above-mentioned failovers/etc...) than building a consumer layer for a web service.

10. Performance tuning. Assuming the alternative is clients running their own queries (and not pre-canned stored procedures), you can be 100% sure that they will start using less than optimal queries. Also, if the web service bounds the set of allowable queries, it can help with your database tuning significantly. I must add that this logic is equally applicable to stored procedures, not unique to web services.

A good list can also be found on this page: 'Encapsulating Database Access: An Agile "Best" Practice'

Just to be crystal clear - some of these issues may not be applicable to ALL situations. Some people don't care about portability. Some people don't need to worry about DB security. Some people don't need to worry about DB scalability.

In my opinion, you should not automatically be exposing your database as a web service. If it turns out you need a service to expose your data, then write one, but not all database access should be done through web services.

1. There is no reason why a database connection should not be secure
2. You can encapsulate the database in a data access layer (possibly Entity Framework)
3. Web services are no easier to consume than a well-written data access layer.

• Web Services form an API, defining the allowed interactions between external systems and the application's data.
• Web Services decouple the database from external interactions and enabling the data layer to be managed independently of those outside influences.
• Allowing access only by Web Services ensures that application logic gets the chance to execute, protecting data integrity.
• Web Services allow the most appropriate authentication/authorization measures to be taken, as opposed to a database requiring a username and password/table level privileges.
• Web Services provide an opportunity for automatic service discovery and configuration to be used.
• Web Services traffic can be encrypted for transit over unsecured networks. Don't know of any direct DB connection solutions that enable that...?

Most of these points go for any formal API, not specifically Web Services.

Writing a web service that simply wraps calls to stored procedures seems to be a misguided approach to designing a good DAL. More than likely, your stored procedures are legacy code left over from a older client-server systems i.e. business rules are buried in the SPs. If that's the case, you're really attempting is creating a silk purse from a sow's ear.

Moreover, your adding a SOAP message protocol layer that adds a performance hit to web apps that have been 'coerced' to dating this 'pig'. I'm working a project right now where our new MVC-4 app has been instructed to use such a DAL. We have the burden of having to change both the WebMethod signature and the SP signature whenever a new user story comes along necessitating such changes; which for us, is every single sprint. Inherent in such a passthru approach is two tightly coupled tiers.

1)Headache of maintaining database is reduced from developers side so that they can focus only on developement.

2)Web service supports communication of different platforms (operating systems like windows,ios,android etc) in a very easy and effective method. for example consider a situation when android application & ios application wants to communicate to a website which is java based so for communication of all the three things webservice is the best solution instead of maintaing three different databases.

In general

1. Web Service level promotes reuse of common data requests for multiple applications
2. Web Service can be set up with version management which deflects many issues arising from application level development. For example if I am new to a project which existing application do I use as a good model for configuring my application to use existing database sources.
3. Web Service has evolved to allow flexible options for sending requests and getting response results back in a common format such as JSON by using a simple URI which means that client applications can be developed using a more common standard that encourages dependable uniform interfaces.

I am just getting stared with ASP.NET Web Api and plan on making data services first.

I have recently been focusing on .NET MVC web applications with the use of the entity framework.

1. If you already use MVC the Web Api also uses MVC with the Api controller so the learning curve to build the services are fairly painless.

I recently found myself in a frustrating predicament with an MVC web app that I was building originally based on Oracle stored procedures. The original version as Oracle 9 or even earlier which presented another problem with Visual Studio 2012 pushing a more modern connection factory approach with load time assemblies finding the right dll files to use based on web config connections and TNS names.

Attempts to connect to the database failed with 'no longer supported' error messages. Out of curiosity I downloaded Oracle 12c and made some application level connections that worked nicely with my TNS names and the load assembly dll and I was able to work with Oracle with no problem.

There were some web services built that were working with connections to the older Oracle version. They were built with methods that were specifically mapped to selected tables however to my disappointment. I would have to write my own.

I was told that the group that was responsible for maintaining the Oracle databases that they would be writing new stored procedures to replace the older ones that I was using to abstract the client interface and business logic layers.

So my first thoughts were that all of the common data requests such as filling up drop down list or auto completes with enterprise wide data be done through data services that would call the Oracle stored procedures. Why repeat that process over each application and have each developer struggle with configuration and version/load assembly, TNS issues?

so....

1. For multiple database server issues such as using Oracle stored procedures in a .NET MVC application that might usually be using EF for the SQL Server data usage why not push those headaches up to Web Api service methods where those configuration issues can be isolated.
2. Again the client interfacing can be done using JavaScript, JQuery and JSON which you are already using if you are doing this using Web Api to make SQL Server data requests.

I am an Application Developer/Analyst and not a DBA so my perspective is one from experience with the never ending frustration of having to constantly modify applications when database tools evolve.