使用 Web 服务来包装数据访问层真的是一个坏主意吗？
我不相信 - 我认为将您的数据暴露给不同的消费者可能会很有用，这些消费者可以在您的网络服务之上构建他们的前端应用程序。
有人可以提供一些示例，说明何时使用 Web 服务来包装数据访问层是一个坏主意吗？
I am not convinced - I think it might be useful to expose your data to different consumers that can build their front-end apps on top of your webservice.
Can someone provide samples of when using web-services to wrap data-access layer is a bad idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据您对“数据访问层”的定义，可能有也可能没有这样做的充分理由。 传统上，分布式 API（例如 Web 服务或 RPC 层）位于下一层。 这具有以下优点：
无需与数据库紧密耦合，您可以调整该层以更好地进行分布式访问 - 例如组织 API 以最大限度地减少往返。
您可以在 API 上添加额外的验证层。 原始数据访问层可能允许将不良数据写入系统。 因此，将其暴露给不受信任的客户端会很糟糕。
您可以采用数据访问层无法实现的方式将应用程序级安全性置于服务层之上。
您可以将
第 1 点和第 2 点意味着您可以在中间层中重用业务规则验证。
第 1 点和第 2 点意味着
公开用于 CRUD 操作的简单 API 也可以通过直接连接到数据库服务器来实现，因此在此之上的 Web 服务层不会为您提供 DBMS 尚未提供的任何内容。 一些数据库引擎还可以直接通过 HTTP 提供查询服务，因此您可以通过大多数防火墙进行隧道传输。 然而，安全方面意味着您几乎肯定不想将其暴露给公共互联网。
虽然理论上您可以通过 Web 服务公开 CRUD 操作（这就是我假设您所说的“数据访问层”的意思），但有一些相当充分的理由不这样做，而且这样做的好处相对较小。
Depending on what you define as a 'data access layer', there may or may not be a good reason to do it. Traditionally, distributed API's such as web services or RPC layers live on the next layer up. This has the following advantages:
Without the tight coupling to the DB You can tune this layer to play nicely with distributed access - for example organising the API to minimise round trips.
You can put an additional layer of validation on the API. A raw data access layer may permit bad data to be written to the system. For this reason, it would be bad to expose it to untrusted clients.
You can put application-level security over the services layer in a way that might not be possible to a data access layer.
Points 1 and 2 mean that you get re-use of the business rule validations in the middle-tier.
Exposing a simple API for CRUD operations can also be achieved by directly connecting to the database server, so a web service layer over the top of this is not going to give you anything that the DBMS doesn't already provide. Some DB engines can also directly serve queries over HTTP so you can tunnel it through most firewalls. However, the security aspects of this mean that you almost certainly don't want to expose this to the public internet.
While you could in theory expose CRUD operations (which is what I am assuming that you mean by 'data access layer') through a web service, there are some fairly good reasons not to do this and relatively little benefit to doing so.
当今世界的主要推动力是云计算或 SaaS 计算。
考虑到这一点，包括 SalesForce (CRM)、Google、Parature（帮助台）等在内的许多主要应用程序都通过 Web 服务公开其应用程序。
这不仅是一个好主意，而且是希望将您的应用程序集成到其环境中的公司认真对待您的应用程序的唯一方法。
也就是说，我能想到的唯一一个使用 Web 服务来包装 DAL 的坏主意的例子是，只有一个应用程序会调用 DAL，并且它处于您的直接开发控制之下。 这是由于跨 Web 服务边界序列化/反序列化数据造成的性能损失。
The major push in today's world is towards cloud or SaaS computing.
With that in mind a lot of major applications including SalesForce (CRM), Google, Parature (helpdesk), etc expose their applications via web services.
It isn't just a good idea, it's the only way to have your application taken seriously by companies looking to integrate it into their environment.
That said, the only example I can think of when utilizing web services to wrap your DAL is bad idea is when only one application will call the DAL and it is under your direct development control. This is due to the performance penalty paid for serializing/deserializing the data across a web service boundary.
好吧，如果您通过没有安全性的 Web 服务公开整个 API，这可能是一个坏主意。
但是，如果您以安全、只读的方式公开其中所需的部分，并且您的客户喜欢它，那肯定是一件好事。
如果你需要说服管理层，请记住“Google 会这么做”。
Well, if you are exposing your entire API over a web service with no security, that might be a bad idea.
But if you are exposing the required parts of it, in a secure, read-only way, and your customers like it, that must surely be a good thing.
If you ever need to persuade management remember that "Google do it."
在 .NET 中，WCF 似乎提供了一种解决 Chris 提到的性能问题的方法。 WCF 应该允许您让数据访问组件在您自己的应用程序的进程内运行，而且还可以轻松地作为 Web 服务公开。 （免责声明：我还没有实际实现这个，只是看了看。）
In .NET, WCF appears to offer a way around the performance hit that Chris mentions. WCF should allow you to to have your data access component run in-process for your own application, but also be readily exposed as a Web service. (Disclaimer: I haven't actually implemented this, just looked at it.)