3

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

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

4

4 回答 4

2

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

  1. 如果没有与 DB 的紧密耦合，您可以调整该层以很好地与分布式访问配合使用 - 例如组织 API 以最大限度地减少往返行程。

  2. 您可以在 API 上添加额外的验证层。原始数据访问层可能允许将不良数据写入系统。出于这个原因，将其暴露给不受信任的客户是不好的。

  3. 您可以采用数据访问层可能无法实现的方式将应用程序级安全性置于服务层之上。

  4. 第 1 点和第 2 点意味着您可以在中间层重用业务规则验证。

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

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

于 2008-11-18T15:57:06.100 回答
2

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

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

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

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

于 2008-11-18T15:57:52.947 回答
1

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

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

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

于 2008-11-18T15:39:50.080 回答
1

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

于 2008-11-18T19:03:49.387 回答