使用 web 服务来包装数据访问层真的是一个坏主意吗？答案

【问题标题】：Is it really such a bad idea to use webservices to wrap data-access layer?使用 web 服务来包装数据访问层真的是一个坏主意吗？
【发布时间】：2010-09-22 21:08:56
【问题描述】：

我不相信 - 我认为将您的数据公开给不同的消费者可能会很有用，这些消费者可以在您的 Web 服务之上构建他们的前端应用程序。

有人可以提供使用 Web 服务包装数据访问层的示例吗？

【问题讨论】：

标签： web-services data-access-layer data-access

【解决方案1】：

根据您对“数据访问层”的定义，可能有也可能没有充分的理由这样做。传统上，分布式 API，如 Web 服务或 RPC 层位于下一层。这样做有以下优点：

如果不与 DB 紧密耦合，您可以调整此层以很好地配合分布式访问 - 例如组织 API 以最大限度地减少往返行程。
您可以在 API 上添加额外的验证层。原始数据访问层可能允许将不良数据写入系统。因此，将其暴露给不受信任的客户端会很糟糕。
您可以将应用程序级别的安全性置于服务层之上，而数据访问层可能无法做到这一点。
第 1 点和第 2 点意味着您可以在中间层重复使用业务规则验证。

为 CRUD 操作公开一个简单的 API 也可以通过直接连接到数据库服务器来实现，因此在此之上的 Web 服务层不会为您提供 DBMS 尚未提供的任何东西。一些数据库引擎还可以直接通过 HTTP 提供查询服务，因此您可以通过大多数防火墙对其进行隧道传输。但是，这意味着您几乎肯定不想将其暴露在公共互联网上。

虽然理论上您可以通过 Web 服务公开 CRUD 操作（我假设您的意思是“数据访问层”），但有一些相当充分的理由不这样做，这样做的好处相对较小.

【讨论】：

【解决方案2】：

当今世界的主要推动力是向云计算或 SaaS 计算发展。

考虑到这一点，包括 SalesForce (CRM)、Google、Parature（帮助台）等在内的许多主要应用程序都通过 Web 服务公开他们的应用程序。

这不仅仅是一个好主意，它还是让希望将其集成到其环境中的公司认真对待您的应用程序的唯一方法。

也就是说，当使用 Web 服务来包装 DAL 时，我能想到的唯一一个坏主意是只有一个应用程序会调用 DAL，并且它在您的直接开发控制之下。这是由于跨 Web 服务边界对数据进行序列化/反序列化会导致性能损失。

【讨论】：

【解决方案3】：

好吧，如果您将整个 API 暴露在没有安全性的 Web 服务上，那可能是个坏主意。

但是，如果您以安全、只读的方式公开它的所需部分，并且您的客户喜欢它，那肯定是一件好事。

如果您需要说服管理层，请记住“Google 这样做”。

【讨论】：

嗯，我通常在与非技术经理交谈时保留这种“嗡嗡声”。
你说的是只读的——如果我只是提供数据，那很好，但是当你生成内容时，你可能也想使用网络服务（具有适当的安全性）
是的，为什么不呢。我稍微说明了光谱的两端。安全的 Web 服务编写有一个中间地带。只是不要在不考虑原因的情况下打开整个 API。

【解决方案4】：

在 .NET 中，WCF 似乎提供了一种解决 Chris 提到的性能问题的方法。 WCF 应该允许您让您的数据访问组件在您自己的应用程序的进程中运行，但也可以很容易地作为 Web 服务公开。（免责声明：我实际上并没有实现这个，只是看着它。）

【讨论】：