作为Web服务的数据访问层——这是个好主意吗?

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

我的观点是,这种方法有点过于工程化,除非你真的需要为不同的消费者有物理上独立的DAL,并且你需要在DAL中进行一些额外的验证/处理(无论如何这是错误的)。

固定非常简单。您可以将SSL与IIS身份验证一起用于公共服务接口。

所以,这些是我的0.03美元

让我们从“企业”软件开发项目发展的角度来看这一点:

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

为了严肃起见,上面的故事有助于建立Web服务的上下文,并了解它们要解决的问题。我们从这个上下文中看到,Web服务实际上包括数据层和业务层。服务层的目的是在多个应用程序之间强制共享一组公共规则。将业务层从服务中去掉让程序员有机会为每个应用程序编写自己的业务代码,这实际上与首先使用服务的目的相反。

也就是说,有可能事情最终会堆积成层,在层中,您拥有对业务的某些部分私有的原始数据服务,而这些“原始”服务反过来又被用于构建构成业务规则层的下游服务。很难确定到底是什么生意。然而,我有一种感觉,这种程度的断开并不常见。

在基于ASMX的Web服务上公开数据,我所面临的唯一真正挑战是想出有效获取数据所需的所有方法。有时,很难让规则遵守应用程序和数据库之间的层。

如果部署到具有AD的Intranet环境中,集成的Windows身份验证是控制哪些人可以和哪些人不能与服务交互的一种极好的方法。它有助于按使用者角色对服务类进行分组,以便 permissions can be controlled declaratively in the Web.config . 我倾向于将read方法保持在与insert update和delete方法不同的服务类中。

避免闲聊的服务电话。当然,在两层系统中避免聊天数据库调用是很好的,但是当您增加层的数量时,您将为聊天调用向Piper支付费用。选择发送较大的对象。例如,如果您有一个具有一些查找的表,那么通过预先查找的值在线路上发送一个对象通常可以节省第二次或第三次调用,并且不应该给系统带来过度的负担。

我希望这些想法有帮助。

我建议你在搬到WCF之前不要这样做。否则,您将通过HTTP在基于文本的XML中来回传递所有数据,这将大大降低速度。在安全性方面,您也没有什么选择,因为仅限于用于加密的SSL。

WCF允许您通过TCP/IP、命名管道或消息队列发送二进制数据,并允许您在安全性方面具有很大的灵活性。