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

Question

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

有人提供使用网络服务来包装数据访问层的样本是不是一个坏主意？

Answer 1

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

1. 没有与数据库的紧密耦合您可以调整此层以便与分布式访问很好地协作 - 例如组织API以最小化往返。

2. 您可以在API上添加额外的验证层。原始数据访问层可以允许将错误数据写入系统。因此，将它暴露给不受信任的客户是不好的。

3. 您可以通过数据访问层可能无法实现的方式将应用程序级安全性放在服务层上。

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

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

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

Answer 2

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

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

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

也就是说，当我利用Web服务来包装你的DAL时，我能想到的唯一例子就是当只有一个应用程序调用DAL并且它处于你的直接开发控制之下时。这是因为在Web服务边界上序列化/反序列化数据所带来的性能损失。

Answer 3

好吧，如果您通过没有安全性的Web服务公开整个API，那可能是个坏主意。

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

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

Answer 4

在.NET中，WCF似乎提供了克里斯提到的性能影响方法。 WCF应该允许您为自己的应用程序在进程中运行数据访问组件，但也可以作为Web服务公开。 （免责声明：我实际上没有实现这一点，只是看了它。）