为什么开发人员应该使用Web服务而不是直接连接到数据库？

Question

我正在寻找一个“十大”列表，列出我们应该通过Web服务连接到远程数据库而不是直接连接到数据库的原因。这是现在的内部辩论，我是亲网络服务但却失去了争论。我对WCF / Web服务有基本的把握，没有其他人可以做到。我们可以做任何我们想要的事情，但我们需要坚持我们现在所选择的任何事情。

这是我想出来的。还有吗？

1. 如果配置正确，WCF Web服务可以更安全。
2. 只需在服务级别（配置文件或重新编译服务）对数据库进行更改。
3. 设置和托管后，Web服务更容易使用。

Answer 1

1. 安全。您不会向除了Web服务器/应用程序用户之外的任何人授予数据库访问权限。

   当您拥有大量用户时，这一点非常重要。您可以避免DB端用户/角色维护的痛苦。

2. DB负载减少。 Web服务可以缓存从DB检索的数据。

3. 数据库连接池（hat / tip @Dogs）。

   Web服务可以使用一小段永久打开的数据库连接。帮助有多种方式：

   • 数据库服务器端的数据库连接池受限。

   • 打开新的数据库连接非常昂贵（特别是对数据库服务器而言）。

4. 容错能力 - 服务可以在主/ DR数据源之间切换，而不会由服务使用者实现故障转移的细节。

5. 可扩展性 - 该服务可以在多个并行数据源之间传播请求，而无需服务使用者实施资源选择的详细信息。

6. 封装。您可以在不影响服务用户的情况下更改基础数据库实施。

7. 数据丰富（包括从客户端自定义到本地化到内部化的任何内容）。基本上任何这些都可能有用，但它们中的任何一个都是数据库的主要负载，并且通常很难在数据库中实现。

8. 可能或可能不适用于您 - 某些架构决策不是DB access友好的。 例如。在Unix上运行的Java服务器可以轻松访问数据库，而在Windows PC上运行的Java客户端不是数据库感知的，也不是您想要的。

9. 可移植性。您的客户可能并非全部使用相同的平台/架构/语言。在每一个中重新创建一个好的数据访问层比为Web服务构建一个消费者层更难（因为它必须考虑上述故障转移等等问题）。

   < / LI>

10. 性能调整。假设替代方案是客户端运行自己的查询（而不是预先存储的预处理过程），您可以100％确定他们将开始使用不太理想的查询。此外，如果Web服务绑定了一组允许的查询，它可以显着帮助您进行数据库调优。我必须补充一点，这种逻辑同样适用于存储过程，而不是Web服务所独有的。

也可以找到一个好的清单on this page: 'Encapsulating Database Access: An Agile "Best" Practice'

只是要清楚 - 其中一些问题可能并不适用于所有情况。有些人不关心便携性。有些人不需要担心数据库安全性。有些人不需要担心数据库可扩展性。

Answer 2

在我看来，您不应该自动将数据库公开为Web服务。如果事实证明您需要一个服务来公开您的数据，那么写一个，但不是所有的数据库访问都应该通过Web服务完成。

1. 没有理由说明数据库连接不安全
2. 您可以将数据库封装在数据访问层（可能是实体框架）
中
3. Web服务并不比编写良好的数据访问层更容易消费。

Answer 3

• Web Services构成一个API，定义外部系统与应用程序数据之间允许的交互。
• Web服务将数据库与外部交互分离，并使数据层能够独立于外部影响进行管理。
• 仅允许Web服务访问，确保应用程序逻辑有机会执行，保护数据完整性。
• Web服务允许采取最合适的身份验证/授权措施，而不是需要用户名和密码/表级权限的数据库。
• Web服务提供了使用自动服务发现和配置的机会。
• 可以对Web服务流量进行加密，以便通过不安全的网络进行传输。不知道任何直接的数据库连接解决方​​案能够实现......？

大多数这些要点适用于任何正式的API，而不是特定的Web服务。

Answer 4

编写一个简单地包含对存储过程的调用的Web服务似乎是设计好DAL的错误方法。很可能，您的存储过程是旧客户端 - 服务器系统遗留的遗留代码，即业务规则隐藏在SP中。如果是这样的话，你真的在​​尝试从母猪的耳朵里创造一个真丝钱包。

此外，您添加了一个SOAP消息协议层，可以为已经“强制”约会“猪”的Web应用程序添加性能影响。我现在正在开展一个项目，我们的新MVC-4应用已被指示使用这样的DAL。每当新的用户故事出现时，我们就必须改变WebMethod签名和SP签名;对我们来说，每一次冲刺都是如此。这种直接方法固有的两个紧密耦合的层次。

Answer 5

1）维护数据库的头痛从开发人员方面减少，以便他们只关注开发。

2）Web服务以非常简单有效的方式支持不同平台（如windows，ios，android等操作系统）的通信。 例如考虑android应用程序＆amp; ios应用程序想要与基于java的网站进行通信，因此对于所有这三件事的通信，webservice是最好的解决方案，而不是维护三个不同的数据库。

Answer 6

一般

1. Web服务级别促进了对多个应用程序的公共数据请求的重用
2. 可以使用版本管理设置Web服务，该版本管理可以解决应用程序级别开发中出现的许多问题。例如，如果我是一个现有应用程序的新手，我将其用作配置应用程序以使用现有数据库源的良好模型。
3. Web Service已经发展到允许灵活的选项，通过使用简单的URI，以通用格式（如JSON）发送请求和获取响应结果 可以使用鼓励的更常见标准开发客户端应用程序 可靠的统一接口。

我只是盯着ASP.NET Web Api并计划首先制作数据服务。

我最近一直专注于使用实体框架的.NET MVC Web应用程序。

1. 如果您已经使用MVC，Web Api也会将MVC与Api控制器一起使用，因此构建服务的学习曲线相当轻松。

我最近发现自己陷入了一个令人沮丧的困境，即我最初基于Oracle存储过程构建的MVC Web应用程序。原始版本为Oracle 9甚至更早版本，它提出了Visual Studio 2012的另一个问题，推出了一种更现代的连接工厂方法，加载时间程序集根据Web配置连接和TNS名称查找要使用的正确dll文件。

尝试连接数据库失败，但不再支持＆＃39;错误消息。出于好奇，我下载了Oracle 12c并进行了一些应用程序级连接，这些连接与我的TNS名称和加载程序集dll很好地协作，我能够毫无问题地使用Oracle。

构建了一些Web服务，这些服务正在与旧的Oracle版本连接。它们是使用专门映射到选定表格的方法构建的，但令我失望。我必须自己写。

我被告知负责维护Oracle数据库的组，他们将编写新的存储过程来替换我用来抽象客户端接口和业务逻辑层的旧存储过程。

所以我的第一个想法是所有常见的数据请求，例如填充下拉列表或自动完成企业级数据，都可以通过调用Oracle存储过程的数据服务完成。为什么要在每个应用程序上重复该过程并让每个开发人员都在配置和版本/负载程序集，TNS问题？

左右....

1. 对于多个数据库服务器问题，例如在.NET MVC应用程序中使用Oracle存储过程（通常可能使用EF进行SQL Server数据使用），为什么不将这些令人头疼的问题推到可以隔离这些配置问题的Web Api服务方法
2. 如果您使用Web Api进行SQL Server数据请求，则可以使用您已经使用的JavaScript，JQuery和JSON完成客户端接口。

我是应用程序开发人员/分析师，而不是DBA，所以我的观点来自于在数据库工具发展过程中不断修改应用程序的永无止境的经历。