.net - 数据访问层作为 Web 服务——这是个好主意吗？

Question

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

谢谢你。

Answer 1

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

从一个非常简单、组织良好且可能几乎没有维护问题的新应用程序开始(如果你幸运的话)。程序员可能是应届毕业生，但系统很年轻或足够干净，他们可以有效并快速响应变更请求。大多数数据库代码可能使用存储过程。不涉及 DBA，也没有正式的规范或路线图。

应用程序增长。经常需要多个程序员同时在系统的相同部分工作。新毕业生发现源代码控制可以帮助他们在多个程序员之间共享代码，并摆脱存储过程，转而采用 n 层设计或 ORM，以便更轻松地对数据库代码进行版本控制。只要每个单独的功能区域都相当隔离，这种方法就可以很好地工作。 DBA 现在可以开始帮助调整查询。仍然没有规范，但可能有一个高级路线图或愿望 list 。

这最终演变成一个互连的应用程序系统，该系统是有机增长的，而不是设计的。变更请求变得困难，因为一个领域的变化会对其他领域产生微妙的影响。为了解决多个应用程序与同一个数据库通信并需要共享通用和复杂业务逻辑的问题，程序员转向面向服务的架构(Web 服务)。旧数据和业务层被分析、组合并重构为一组通用的 Web 服务。大多数程序员现在甚至不再知道如何连接到他们的数据库——只有那些在核心服务上工作的人才被允许这样做，甚至他们倾向于将任何实际的 SQL 留给 DBA 团队。如果尚未使用单元测试，则现在发现它是设置持续集成系统或问题跟踪器的一部分。

系统继续增长，但业务增长更快。事情通常有效；质量很好，性能不是很好，但仍然可以接受。现在肯定有一个规范和问题跟踪器；事实上，如果没有相关的跟踪号，就不可能做任何事情。问题是变化速度太慢。程序员和应用程序之间的流程层阻止他们以具有成本效益的方式跟上业务。有人发现了敏捷方法。

回到第一步。

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

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