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

Question

我已经研究了一段时间，实际上已经为一些ASP.NET 2.0网站创建了一个原型ASP.NET Web服务作为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美元

Answer 3

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

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

避免繁琐的服务电话。当然，在2层系统中避免繁琐的数据库调用是很好的，但是当你增加层数时，你会为吹嘘的电话付费。选择发送更大的对象。例如，如果您有一个包含少量查找的表，则使用预先查找的值通过线路发送对象通常可以节省您的第二次或第三次调用，并且不应该对系统造成不必要的负担。

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

Answer 4

我建议不要这样做，直到你可以转到WCF。否则，您将通过HTTP在基于文本的XML中来回传递所有数据，这将大大减慢速度。您对安全性的选择也很少，仅限SSL加密。

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