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

Question

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

谢谢.

Answer 1

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

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

为了再次认真,上面的故事有助于建立Web服务的上下文并理解它们要解决的问题.从这个上下文我们可以看出,Web服务确实包含数据层和业务层.服务层的目的是强制在多个应用程序之间共享一组通用规则.让业务层脱离您的服务使程序员有机会为每个应用程序编写自己的业务代码,这对于首先使用服务的目的而言实际上是适得其反的.

也就是说,事情最终可能堆叠在一起,您拥有对业务某些部分私有的原始数据服务,而这些"原始"服务又用于构建构成业务的下游服务规则层.很难确定业务究竟在做什么.但是,我意识到这种断开程度不太常见.

Answer 2

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

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

保护安全可能非常简单。您可以将 SSL 与 IIS 身份验证一起用于公共服务接口。

所以，这些是我的 0.03 美元