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

93

我正在寻找“十佳”列表，列出为什么我们应该通过Web服务连接到远程数据库而不是直接连接到数据库。目前这是内部辩论，我是支持Web服务的专家，但失败了。我对WCF / Web服务有基本的了解，其他人没有。我们可以做任何我们想前进的事情，但我们需要坚持现在选择的一切。

这是我想出的。还有吗

  1. 如果配置正确，则WCF Web服务可以更安全。
  2. 对数据库的更改仅需要在服务级别（配置文件或重新编译服务）进行。
  3. 设置和托管后，Web服务将更易于使用。
wcf  web-services 
— 德纳利·硬尾
source

Answers:

120

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

    当您有大量用户时，这尤为重要。您避免了数据库方面用户/角色维护的麻烦。

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

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

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

    • 数据库连接池在数据库服务器端受到限制。

    • 打开新的数据库连接非常昂贵（尤其是对于数据库服务器）。

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

  5. 可伸缩性-服务可以在多个并行数据源之间分发请求，而无需让服务使用者实现资源选择的详细信息。

  6. 封装。您可以更改基础数据库的实现，而不会影响服务用户。

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

  8. 可能适用或可能不适用于您-某些体系结构决策对DB acces不友好。例如，在Unix上运行的Java Server可以轻松访问数据库，而在Windows PC上运行的Java客户端不支持数据库，您也不希望这样做。

  9. 可移植性。您的客户不一定都在同一平台/体系结构/语言上。与为Web服务构建使用者层相比，在其中的每个层中重新创建一个良好的数据访问层都更加困难（因为它必须考虑到上述故障转移/等问题）。

  10. 性能调优。假设替代方法是客户端运行自己的查询（而不是预先安装的存储过程），则可以100％确保它们将开始使用少于最佳查询的状态。另外，如果Web服务限制了允许查询的范围，则可以大大帮助您进行数据库调整。我必须补充一点，该逻辑同样适用于存储过程，而不是Web服务所独有。

在此页面上也可以找到一个好的列表：“封装数据库访问：敏捷的“最佳”实践”

只是要明确地说-其中一些问题可能并不适用于所有情况。有些人不关心可移植性。有些人不需要担心数据库安全性。有些人不需要担心数据库可伸缩性。

— 数字电视
source
26
抱歉，不同意。1.因此，您授予数据库访问组而不是单个主体的权限-没什么区别。2.任何应用程序都可以缓存数据。在任何情况下，可以跨多个用户缓存的数据类型通常是小容量数据。3.在任何情况下，FT都应由数据库处理。4.这不是开箱即用的功能，必须进行编程。5.您的数据访问层应进行封装。6.同样的事情。7.真的吗？JDBC不在客户端中运行吗？8.好点，重要的是，很少见。9.查询与SP并不是问题的一部分。
— 约翰·桑德斯
7
1.尝试使用多个角色在5000个用户中进行管理。伸缩性不再那么好了。2.完全取决于应用程序。我们当前的案例中有一个查询的缓存结果实例，在超级优化的情况下，该实例需要20分钟才能运行，而且我们每天至少需要在不同的应用程序中运行100次。3. FT是在多个级别上处理的。您是什么意思“应该由数据库处理”？
— DVK 2010年
4
4.当然必须对其进行编程。但是可以将其编程到服务中一次，也可以编程到具有不同功能的各种平台上的无数客户端应用程序中。有很大的不同。不必介意用于负载平衡的配置管理问题。5.相同的推理。您不需要重新实现DAL。实际上，您可以将Web服务视为可移植的DAL，以减轻您的负担。7.我们不希望每个客户端都打开数据库连接。要求这么大吗？同样，您忘记了1-5点。
— DVK 2010年
2
8.> 1个客户端体系结构经常发生。事实上，我一生中从未遇到过这样的情况，但是我一直专注于金融领域。9.不是。我基本上是在扮演恶魔的拥护者。
— DVK 2010年
2
我喜欢这个答案，但是我认为您跳过了最重要的一点之一：连接池。如果您有1,000,000个客户端，则将有1,000,000个打开的连接，或者数百万个连接在不断打开和关闭。关于计算机组织的基本直觉告诉我们，精心调整的数百个长期连接池在天文效率上要比拥有100万个长期连接或数百万个短期连接更为有效。HikariCP的文档很好地阐述了这个想法：github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
— Dogs
15

我认为，您不应自动将数据库作为Web服务公开。如果事实证明您需要一种服务来公开您的数据，请编写一个，但是并非所有数据库访问都应该通过Web服务来完成。

  1. 没有理由为什么数据库连接不安全
  2. 您可以将数据库封装在数据访问层（可能是实体框架）中
  3. Web服务比编写良好的数据访问层更容易使用。
— 约翰·桑德斯
source
为什么需要XML？还有要轻得多解析JSON，CSV简单的平面数据，等等
— DVK
这不是“没有充分的理由”。如前所述，根据您对未来开发的要求和期望，您的项目可能有必要。
— 克里斯·斯图尔特
我编写WS来消耗DAL。您建议在哪个端口上暴露DAL？
— samis
@samus没关系。
— 约翰·桑德斯
“没有理由不保证数据库连接的安全性”，例如，很难保护Windows客户端和数据库之间的连接的安全。确实很难实现安全连接！
— NoChance
12
  • Web服务形成一个API，用于定义外部系统与应用程序数据之间允许的交互。
  • Web服务使数据库与外部交互脱钩，并使数据层的管理不受外界影响的影响。
  • 仅通过Web服务允许访问可确保应用程序逻辑有机会执行，从而保护数据完整性。
  • 与要求用户名和密码/表级特权的数据库相反，Web服务允许采取最适当的身份验证/授权措施。
  • Web服务为自动服务发现和配置提供了机会。
  • 可以对Web服务流量进行加密，以便在不安全的网络上传输。不知道有任何直接的数据库连接解决方​​案可以实现...？

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

— 龙虾
source
1
是的，这就是我要说的，如果您只有一个应用程序访问数据库，那么所有点也可用于常规API。
— Ignacio Soler Garcia 2015年
“ Web服务形成一个API，定义了外部系统与应用程序数据之间允许的交互。” 您也可以使用数据库来做到这一点。
— 擦鞋
“仅允许Web服务进行访问，以确保应用程序逻辑有机会执行，从而保护数据完整性。” -我认为数据完整性应仅是DBMS的一部分。
— 擦鞋
@Shoe可以通过数据库强制执行尽可能多的完整性，但是随着数据开始填充并暴露出缺点（例如需要进行一些输入验证），可以在应用程序级别强制执行此操作（尽管我想在数据库级别强制执行）客户端，如果验证规则取决于仅服务器已知的数据（从客户端应用程序保留），则有时需要在服务器端进行处理。改变数据库的完整性规则集是否大不了？我以为这不是一件小事？
— samis
2

编写仅包装对存储过程的调用的Web服务似乎是设计好的DAL的错误方法。您的存储过程很有可能是旧的客户端-服务器系统遗留的遗留代码，即业务规则埋在SP中。如果是这种情况，您实际上是在尝试从母猪的耳朵中创建一个丝绸钱包。

此外，您添加了一个SOAP消息协议层，从而对已经“强制”约会此“猪”的Web应用程序增加了性能影响。我现在正在一个项目中，我们的新MVC-4应用已被指示使用这种DAL。每当有新的用户案例需要进行更改时，我们都必须更改WebMethod签名和SP签名。对我们来说，这是每一个冲刺。这种直通方法固有的是两个紧密耦合的层。

— 塞瓦萨纳基德
source
1
Web API解决了WCF / SOAP膨胀问题。现在就像一只轻盈，健康，敏捷的猫科动物；RESTful服务所需的一切。
— samis
从理论上讲，使用Web服务调用存储的proc并没有错。
— NoChance
2

1）从开发人员的角度减轻了维护数据库的麻烦，因此他们只能专注于开发。

2）Web服务以一种非常简单有效的方法支持不同平台（Windows，iOS，Android等操作系统）之间的通信。例如，考虑当android应用程序和ios应用程序希望与基于Java的网站进行通信的情况，因此对于所有三项通信而言，webservice是最佳解决方案，而不是维护三个不同的数据库。

— 罗汉
source
1

一般来说

  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文件。

尝试连接到数据库失败，并显示“不再受支持”错误消息。出于好奇，我下载了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，因此我的观点是从经验中获得的，这是随着数据库工具的发展而不断修改应用程序所带来的无尽挫败感。

— 布赖恩·奎因
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.