我正在寻找我们应该通过 Web 服务连接到远程数据库而不是直接连接到数据库的“十大”原因列表。现在这是一场内部辩论，我支持网络服务，但输掉了这场辩论。我对 WCF/Web 服务有了基本的掌握，其他人没有。我们可以做任何我们想做的事情，但我们需要坚持我们现在选择的任何事情。
这是我的想法。还有吗？
- 如果配置正确，WCF Web 服务可以更加安全。
- 只需在服务级别(配置文件或重新编译服务)对数据库进行更改。
- 一旦设置并托管，网络服务就更容易使用。
最佳答案
安全。除了网络服务器/应用程序用户之外，您不会向任何人授予数据库访问权限。
当您拥有大量用户时，这一点尤为重要。您避免了数据库端用户/角色维护的痛苦。
数据库负载减少。 Web 服务可以缓存从数据库检索的数据。
数据库连接池(帽子/提示@Dogs)。
Web 服务可以使用一小部分永久打开的数据库连接。可以通过多种方式提供帮助:
数据库连接池在数据库服务器端受到限制。
打开新的数据库连接的成本非常高(特别是对于数据库服务器而言)。
容错能力 - 服务可以在主数据源/灾难恢复数据源之间切换，而无需服务使用者实现故障转移的详细信息。
可扩展性 - 服务可以在多个并行数据源之间传播请求，而无需服务使用者实现资源选择的详细信息。
封装。您可以更改底层数据库实现，而不会影响服务用户。
数据丰富(这包括从客户端定制到本地化再到内部化的任何内容)。基本上，这些中的任何一个都可能有用，但它们中的任何一个都是数据库的主要负载，并且通常很难在数据库内实现。
可能适用也可能不适用于您 - 某些架构决策不适合数据库访问。 例如。在 Unix 上运行的 Java 服务器可以轻松访问数据库，而在 Windows PC 上运行的 Java 客户端不支持数据库，您也不希望它这么做。
便携性。您的客户可能并不都使用相同的平台/架构/语言。在每个层中重新创建良好的数据访问层比为 Web 服务构建消费者层更困难(因为它必须考虑上述故障转移等问题)。
性能调整。假设替代方案是客户端运行自己的查询(而不是预先固定的存储过程)，您可以 100% 确定他们将开始使用不是最佳的查询。此外，如果 Web 服务限制了允许的查询集，它可以显着帮助您进行数据库调整。我必须补充一点，这个逻辑同样适用于存储过程，而不是 Web 服务所独有的。
还可以找到一个不错的列表on this page: 'Encapsulating Database Access: An Agile "Best" Practice'
需要澄清的是 - 其中一些问题可能并不适用于所有情况。有些人不关心可移植性。有些人不需要担心数据库安全。有些人不需要担心数据库的可扩展性。
关于wcf - 为什么开发人员应该使用 Web 服务而不是直接连接到数据库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2142070/