为什么开发人员应该使用Web服务而不是直接连接到数据库？
我正在寻找一个“前十名”的原因列表，我们应该通过Web服务连接到远程数据库，而不是直接连接到数据库。 这是一个内部的辩论，我现在是亲networking服务，但失去了争论。 我有一个WCF / Web服务的基本把握，没有其他人做的。 我们可以做任何我们想要的事情，但是我们需要坚持我们现在select的任何事情。
这是我想出来的。 还有吗？
- 如果configuration正确，WCF Web服务可以更安全。
- 对数据库的更改只需要在服务级别（configuration文件或重新编译服务）进行。
- 一旦安装和托pipe，Web服务更容易使用。
-
安全。 您不会授予任何人访问数据库的权限，除了Web服务器/应用程序用户。
当你有大量的用户时，这是特别重要的。 您可以避免DB侧的用户/angular色维护带来的痛苦。
-
DB负载减less。 Web服务可以caching从数据库检索到的数据。
-
容错能力 – 服务可以在主/ DR数据源之间进行切换，而不需要服务使用者实现故障切换的细节。
-
可扩展性 – 服务可以在多个并行数据源之间传播请求，而不需要服务使用者实现资源拣选的细节。
-
封装。 您可以更改底层数据库实施，而不会影响服务用户。
-
数据丰富（包括从客户端定制到本地化到内部化）。 基本上任何这些都可能是有用的，但其中任何一个都是数据库的主要负载，并且往往很难在数据库中实现。
-
可能会或可能不适用于您 – 某些架构决策不是数据库访问友好的。 例如，在Unix上运行的Java服务器可以方便地访问数据库，而在Windows PC上运行的Java客户端不会感知数据库，也不需要它。
-
可移植性。 你的客户可能并不都是在同一个平台/架构/语言上。 在每一个数据访问层中重新创build一个好的数据访问层比构build一个Web服务的消费层要困难得多（因为它必须考虑到上述故障转移等的问题）。
-
性能调整。 假设替代scheme是客户端运行自己的查询（而不是预先存储的存储过程），则可以100％确定他们将开始使用less于最佳查询。 而且，如果Web服务绑定了允许的查询集合，它可以帮助您显着调整数据库的大小。 我必须补充一点，这个逻辑同样适用于存储过程，而不是Web服务独有的。
在这个页面上还可以find一个好的列表：“封装数据库访问：敏捷”最佳“实践”
只是要清楚地说明 – 其中一些问题可能不适用于所有情况。 有些人不关心可移植性。 有些人不需要担心数据库安全。 有些人不需要担心DB的可扩展性。
在我看来，你不应该自动暴露你的数据库作为一个Web服务。 如果事实certificate，你需要一个服务来暴露你的数据，然后写一个，但不是所有的数据库访问应该通过Web服务来完成。
- 数据库连接不安全是没有道理的
- 您可以将数据库封装在数据访问层（可能是Entity Framework）
- Web服务并不比编写良好的数据访问层更容易使用。
- Web服务组成一个API，定义外部系统和应用程序数据之间允许的交互。
- Web服务将数据库与外部交互分离，并使数据层独立于外部影响进行pipe理。
- 只允许Web服务访问，确保应用程序逻辑有机会执行，保护数据的完整性。
- Web服务允许采取最恰当的authentication/授权措施，而不是需要用户名和密码/表级别权限的数据库。
- Web服务提供了使用自动服务发现和configuration的机会。
- Web服务stream量可以encryption，以便在不安全的networking上传输。 不知道任何直接的数据库连接解决方案，使… …？
大多数这些点都适用于任何正式的API，而不是专门的Web服务。
1）从开发者的angular度来看，维护数据库的难度减less了，所以他们只关注开发。
2）Web服务以非常简单有效的方式支持不同平台（windows，ios，android等操作系统）的通信。 例如考虑一下android应用程序和ios应用程序想要与基于java的网站进行通信的情况，以便所有三件事情的通信webservice是最好的解决scheme，而不是维护三个不同的数据库。
编写一个简单的调用存储过程的Web服务似乎是devise一个好的DAL的一个误导的方法。 您的存储过程很可能是旧版客户机 – 服务器系统遗留的旧代码，即业务规则隐藏在SP中。 如果是这样的话，你真的试图从母猪的耳朵上创造一个丝绸钱包。
此外，您还可以添加一个SOAP消息协议层，为那些已被“强制”约束到这个“猪”的web应用程序添加性能。 我正在开发一个项目，我们的新MVC-4应用程序已经被指示使用这样一个DAL。 当新的用户故事出现时，我们有责任不得不改变WebMethod签名和SP签名; 对我们来说，是每一个冲刺。 这种通行方式固有的是两个紧密联系的层次。
一般来说
- Web服务级别促进了对多个应用程序的通用数据请求的重用
- Web服务可以通过版本pipe理来设置，从而避免应用程序开发中出现的许多问题。 例如，如果我是一个新的项目，现有的应用程序可以用作configuration我的应用程序以使用现有数据库源的良好模型。
- Web服务已经发展到允许使用简单的URI来发送请求并以诸如JSON的通用格式获得响应结果的灵活选项，这意味着客户端应用程序可以使用鼓励可靠的统一接口的更通用的标准来开发。
我只是盯着ASP.NET Web Api，并计划首先提供数据服务。
我最近一直在关注使用entity framework的.NET MVC Web应用程序。
- 如果你已经使用了MVC，那么Web Api也使用了Api控制器的MVC，所以构build这些服务的学习曲线是相当痛苦的。
最近我发现自己处于一个令人沮丧的困境，那就是我最初基于Oracle存储过程构build的MVC Web应用程序。 原始版本为Oracle 9或更早版本，这提出了Visual Studio 2012的另一个问题，推出了一个更现代的连接工厂方法，加载时程序集根据Webconfiguration连接和TNS名称find正确的dll文件。
尝试连接到数据库失败，出现“不再支持”错误消息。 出于好奇，我下载了Oracle 12c，并创build了一些与我的TNS名称和加载程序集DLL很好地配合的应用程序级别的连接，并且我能够与Oracle合作，没有任何问题。
有一些Web服务构build了与旧版Oracle版本的连接。 它们是用专门映射到选定表格的方法构build的，但令我失望的是。 我将不得不写我自己的。
我被告知负责维护Oracle数据库的组织将会编写新的存储过程来replace我用来抽象客户机接口和业务逻辑层的旧数据库。
所以我首先想到的是，所有常见的数据请求，如填充下拉列表或自动完成与企业范围的数据完成通过数据服务，将调用Oracle存储过程。 为什么要在每个应用程序上重复这个过程，并让每个开发人员在configuration和版本/装入程序集，TNS问题上挣扎？
所以….
- 对于多个数据库服务器问题，例如在.NET MVC应用程序中使用Oracle存储过程，通常可能使用EF作为SQL Server数据使用情况，为什么不把这些问题推到可以隔离这些configuration问题的Web Api服务方法。
- 客户端接口也可以使用JavaScript，JQuery和JSON来完成，如果您正在使用Web Api来完成SQL Server数据请求，那么您已经使用了JQuery和JSON。
我是应用程序开发人员/分析师，而不是数据库pipe理员，所以我的观点是从数据库工具发展时不断修改应用程序的永无止境的挫败经验。
