什么时候不应该使用Web服务?

对于数据访问来说,Web服务绝对是一个可怕的选择。它的开销和复杂性几乎为零。

如果你的应用程序要在一台机器上运行,为什么要拒绝它进行进程内数据访问调用的能力?我说的不是直接从您的UI代码访问数据库,而是将您的存储库抽象出来,但仍然将它们的程序集包含在您正在运行的网站中。

在某些情况下,我会推荐Web服务(我假设您是指SOAP),但这主要是为了实现互操作性。

服务的粒度在这里也存在问题。SOA意义上的服务将封装操作或业务流程。数据访问方法只是这个过程的一部分。

换言之:

  - someService.SaveOrder(order);  // <-- bad
    // some other code for shipping, charging, emailing, etc

  - someService.FulfillOrder(order);  //<-- better
    //the service encapsulates the entire process

以Web服务为目的的Web服务是不负责任的编程。

Nick Harrison是夏洛特的一名优秀开发人员,他提出了使用Web服务有意义的这些场景:

• 在Web场中,有多个Web服务器托管网站,所有这些服务器都指向运行在另一个Web服务器上的Web服务。这允许在多个服务器上分配负载。
• 客户端/服务器,其中Windows窗体应用程序可以调用Web服务。
• 跨平台
• 通过防火墙

仅仅因为工具生成了一堆存根并不意味着它是一个很好的用途。WS-*在您公开的场景中表现出色 服务 外部各方。这意味着每个操作都应该在业务流程的粒度上,而不是数据访问。

大量的标准可以用来非常详细地描述合同的不同方面,并且(假设的)完全兼容的WS-Stack可以从第三方开发人员那里消除许多痛苦,甚至可以让传说中的点击式集成a'la Yahoo Pipes。通过良好的治理控制,您可以根据需要改进公共接口并管理向后兼容性。

所有这些几乎不可能自动生成。C存根生成器只知道类的物理接口,但不知道所涉及的语义。见 this paper 更详细的讨论。

如果您正在构建一个网站,那么就构建一个网站。如果希望在应用程序中使用异步消息传递,请使用 MSMQ . 如果要向内部客户端公开数据,请使用 POX . 如果您需要高效的二进制消息格式,请检查Google的 Protocol Buffers 或者如果您需要RPC检查 Hessian for C# 或DCOM。

Web服务是一种粗粒度的集成解决方案。他们是僵化的,他们比其他选择慢,他们花了太多的精力去做好(如果做得不好,几乎是毫无意义的)。

总结:“Web服务应该在什么时候 不 用吗?”-任何时候没有它你都能逃走

如果你只是在为你的内部网编写一个小的(不到50个用户)Web应用程序,那么一个Web服务似乎就太危险了。尤其是如果它的主要功能(提供对许多服务的单点访问)将不会被使用。

我同意在小规模的Web应用中使用Web服务会增加一层看起来不合理的复杂性。我的大多数解决方案,互联网和内部网,10-50个用户,不使用网络服务。我很高兴别人也这么想…我以为只有我一个人。

对于小规模的Web应用程序,我认为使用Web服务通常是一个很好的主意,您可以使用它轻松地将Web服务器与数据层分离。有了StraightOfrward开发需求和出色的工具,我看不出问题所在。

然而 不要 在以下情况下使用Web服务:

• 当您必须使用HTTP作为数据的传输和XML序列化,并且您需要大量不同的数据位时,需要同步且经常使用。无论是REST、SOAP还是WS-*都会遇到性能问题。你打的电话越多,你的系统就越慢。如果您不想频繁、异步地使用中等大小的数据块,并且可以使用直接的TCPIP(例如,wcf nettcpbinding),那么您会更好。
• 当您需要从您的Web服务查询数据并将其与其他数据源连接起来时,应该鼓励您创建一个数据仓库,该仓库可以使用来自EnterPrize的适当整合和合理化的数据进行填充。

这是我的经验,希望能有所帮助。

对于小规模的网络应用程序(你必须问一个问题,“它会一直保持小规模吗?”但是)使用Web服务、分离的业务层、数据层等可能会造成过度破坏。

在有人向我开枪之前,我确实同意,层之间的逻辑分离以及单元测试、连续集成等都是非常出色的。在我现在的角色里,没有他们我会完全迷路,在角落里摇摆不定。但是,对于一个非常小规模的网络应用程序,例如,跟踪36名员工的联系电话和地址,成本/效益分析将表明,上面列出的所有“细节”都是多余的。

然而。。。记得问一个问题“它会一直保持小规模吗?”-)