为什么开发人员应该使用 Web 服务而不是直接连接到数据库? [英] Why should a developer use web services instead of direct connections to a db?
问题描述
我正在寻找我们应该通过 Web 服务连接到远程数据库而不是直接连接到数据库的十大"原因列表.这是现在的内部辩论，我支持网络服务，但失去了争论.我对 WCF/Web 服务有基本的了解，其他人没有.我们可以随心所欲地前进，但我们需要坚持我们现在选择的一切.
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?
- 如果配置正确，WCF Web 服务可以更加安全.
- 只需在服务级别(配置文件或重新编译服务)即可更改数据库.
- 设置和托管后，网络服务更易于使用.
推荐答案
安全.除了网络服务器/应用程序用户之外，您不会向任何人授予数据库访问权限.
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.
数据库负载减少.Web 服务可以缓存它从数据库中检索到的数据.
DB load reduction. Web service can cache the data it retrieved from DB.
数据库连接池(hat/tip @Dogs).
Database connection pooling (hat/tip @Dogs).
Web 服务可以使用永久打开的数据库连接的小型池.以多种方式提供帮助:
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).
容错能力 - 服务可以在主/灾难恢复数据源之间切换，而无需服务使用者实施故障转移的细节.
Ability for fault tolerance - the service can switch between primary/DR data sources without having details of fail-over be implemented by service consumers.
可扩展性 - 服务可以在多个并行数据源之间传播请求，而无需服务消费者实施资源选择的详细信息.
Scalability - the service can spread requests between several parallel data sources without having details of the resource picking be implemented by service consumers.
封装.您可以在不影响服务用户的情况下更改底层数据库实现.
Encapsulation. You can change underlying DB implementation without impacting service users.
数据丰富(包括从客户定制到本地化再到内部化的任何内容).基本上，其中任何一个都可能有用，但其中任何一个都是数据库的主要负载，并且通常很难在数据库中实现.
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.
可能适用也可能不适用于您 - 某些架构决策对数据库访问不友好.例如.在 Unix 上运行的 Java 服务器可以轻松访问数据库，而在 Windows PC 上运行的 Java 客户端不知道数据库，您也不希望它知道.
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.
便携性.您的客户可能并非都在同一平台/架构/语言上.在其中的每一个中重新创建一个好的数据访问层(因为它必须考虑到诸如上述故障转移等问题...)比为 Web 服务构建一个消费者层更难.
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.
性能调整.假设替代方案是客户端运行他们自己的查询(而不是预装的存储过程)，您可以 100% 确定他们将开始使用不太理想的查询.此外，如果 Web 服务限制了允许的查询集，它可以显着帮助您进行数据库调优.我必须补充一点，此逻辑同样适用于存储过程，而不是 Web 服务独有的.
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.
也可以在在此页面上找到一个很好的列表:封装数据库访问:敏捷"最佳练习'
明确一点 - 其中一些问题可能并不适用于所有情况.有些人不关心便携性.有些人不需要担心数据库安全.有些人不需要担心数据库的可扩展性.
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.
这篇关于为什么开发人员应该使用 Web 服务而不是直接连接到数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
