数据访问层作为 Web 服务——这是个好主意吗？答案

【问题标题】：Data Access Layer as a web service -- Is this a good idea?数据访问层作为 Web 服务——这是个好主意吗？
【发布时间】：2011-03-31 08:10:12
【问题描述】：

我已经研究了一段时间，实际上已经为一些 ASP.NET 2.0 网站创建了一个原型 ASP.NET Web 服务作为 DAL。只是想向那些成功地将 DAL 作为 Web 服务推出的更有经验的开发人员寻求一些见解/建议。将 DAL 部署为 Web 服务有哪些缺点/风险？保护或验证使用此 Web 服务的最佳方法是什么？ WCF 是不可能的，我将在 VS 2005 中进行编码。

谢谢。

【问题讨论】：

您是在询问与客户端直接数据访问相比，与 Web 服务交付数据相关的缺点，还是一般构建 DAL 时需要考虑的事项？
我在问是否将 DAL 用作 Web 服务一般来说是一个好主意，以便在几个 ASP.NET 站点之间重用。

标签： .net asp.net oop components

【解决方案1】：

让我们从“企业”软件开发项目演变的角度来看这个：

从一个非常简单、组织良好的新应用程序开始，几乎没有维护问题（如果幸运的话）。程序员可能是应届毕业生，但系统很年轻或足够干净，他们可以有效并快速响应变更请求。大多数数据库代码可能使用存储过程。不涉及 DBA，也没有正式的规范或路线图。
应用程序增长。经常需要多个程序员同时在系统的相同部分工作。新毕业生发现源代码控制可以帮助他们在多个程序员之间共享代码，并摆脱存储过程，转而采用 n 层设计或 ORM，以便更轻松地对数据库代码进行版本控制。只要每个单独的功能区域都相当隔离，这种方法就可以很好地工作。 DBA 现在可以开始帮助调整查询。仍然没有规范，但可能有一个高级路线图或愿望清单。
这最终演变成一个互连的应用程序系统，该系统以有机方式而非设计方式发展。变更请求变得困难，因为一个领域的变化会对其他领域产生微妙的影响。为了解决多个应用程序与同一个数据库通信并需要共享通用和复杂业务逻辑的问题，程序员转向了面向服务的架构（Web 服务）。旧数据和业务层被分析、组合并重构为一组通用的 Web 服务。大多数程序员现在甚至不再知道如何连接到他们的数据库——只有那些在核心服务上工作的人才被允许这样做，甚至他们倾向于将任何实际的 SQL 留给 DBA 团队。如果尚未使用单元测试，则现在发现它是设置持续集成系统或问题跟踪器的一部分。
系统继续增长，但业务增长更快。事情通常有效；质量很好，性能不是很好，但仍然可以接受。现在肯定有一个规范和问题跟踪器；事实上，如果没有相关的跟踪号，就不可能做任何事情。问题是变化速度太慢。程序员和应用程序之间的流程层阻止他们以具有成本效益的方式跟上业务。有人发现了敏捷方法。
返回第一步。

再次严肃地说，上面的故事有助于建立 Web 服务的上下文并理解它们要解决的问题。我们从这个上下文中看到，Web 服务确实包含数据层和业务层。服务层的目的是强制在多个应用程序之间共享一组通用规则。将业务层排除在您的服务之外，让程序员有机会为每个应用程序编写自己的业务代码，而这对于最初使用服务的目的确实适得其反。

也就是说，事情最终可能会分层堆叠，其中您拥有对业务的某些部分私有的原始数据服务，而这些“原始”服务又用于构建下游服务构成业务规则层。很难确切地知道企业到底在做什么。不过，我感觉这种程度的脱节不太常见。

【讨论】：

非常感谢乔尔。您刚刚为我的编程思维开辟了一个全新的视角。在某种程度上，您只是总结了我在第 3 点之前使用的系统架构状态。
好故事 :) 总结得差不多了.. +1

【解决方案2】：

我认为，这种方法的最大缺点是调用 Web 服务的额外开销。如果您需要频繁查询/更新 DAL，这可能会变得很慢。

我的观点是，这种方法有点过度设计，除非您确实需要为不同的消费者提供物理上独立的 DAL，并且您需要在 DAL 中进行一些额外的验证/处理（无论如何这有点错误）。

保护可以很简单。您可以将 SSL 与 IIS 身份验证一起用于您的公共服务接口。

所以，这些是我的 0.03 美元

【讨论】：

这个公认的答案是在 2010 年发布的，但如今，在 2018 年，基于微服务的架构已成为一种规范（主要是为了可扩展性），其中一个应用程序被拆分为多个微型 Web 服务，每个服务都必须处理拥有自己的数据源，即微服务中的 BLL 拆分，微服务中的 DAL 拆分等。

【解决方案3】：

在通过基于 ASMX 的 Web 服务公开数据时，我面临的唯一真正挑战是构想有效获取数据所需的所有方法。有时很难有纪律来尊重应用程序和数据库之间的层。

如果您使用 AD 部署到 Intranet 环境，集成 Windows 身份验证是控制谁可以和不能与服务交互的绝佳方式。按消费者角色对服务类进行分组很有帮助，这样permissions can be controlled declaratively in the Web.config。我倾向于将读取方法保留在与插入更新和删除方法不同的服务类中

避免喋喋不休的服务电话。当然，在 2 层系统中避免繁琐的数据库调用是很好的，但是当您增加层数时，您会为繁琐的调用付费。选择发送较大的对象。例如，如果您有一个包含几次查找的表，则通过网络发送具有预先查找的值的对象通常会为您节省第二次或第三次调用，并且不会对系统造成过度负担。

我希望这些想法有所帮助。

【讨论】：

【解决方案4】：

在您可以迁移到 WCF 之前，我建议您不要这样做。否则，您将在基于文本的 XML 中通过 HTTP 来回传递所有数据，这将大大减慢速度。您在安全性方面也几乎没有选择余地，仅限于使用 SSL 进行加密。

WCF 将允许您通过 TCP/IP、命名管道或消息队列发送二进制数据，并在安全性方面为您提供极大的灵活性。

【讨论】：

感谢约翰的深刻见解。无论如何，只是为了分享更多细节，我正处于 ASP Classic 到 ASP.NET 2.0 迁移的早期阶段。目前我们有一些 ASP 经典站点与托管数据访问层的 COM 服务器进行通信。
那么，为什么不再迁移到 WCF 的原因是什么？而且，您为什么停留在 ASP.NET 2.0 上？从 ASP Classic 转移到其他任何东西已经是一个巨大的飞跃。我认为没有理由不迁移到一个相当现代的 .NET 版本，它有许多功能可以让您的迁移更顺利。
好吧，假设客户不会很快升级到高于 2.0 的版本。
好的，但是您应该让客户知道 .NET 3.5 SP1 只不过是带有一些额外程序集的 .NET 2.0 SP2。它使用与 .NET 2.0 相同的 CLR。我不会向该客户端推荐 .NET 4.0，因为是一个新的 CLR。
@John - 为客户辩护，无论是否只是额外的程序集，3.5 的安装程序都是野兽