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

使用Web服务通常是一种出色的架构方法.而且,随着.Net中WCF的出现,它变得更好.

但是,根据我的经验,有些人似乎认为应该始终在数据访问层中使用Web服务来调用数据库.我不认为Web服务是通用解决方案.

我正在考虑使用几十个用户的小型Intranet应用程序.Web应用程序及其Web服务部署到一个Web服务器,而不是Web场.将来不会有另一个可以使用此特定Web服务的Web应用程序.在我看来,调用Web服务的成本不必要地增加了Web服务器的负担.进程间调用受到性能影响.维护和调试Web应用程序和Web服务的代码更加复杂.部署也是如此.我只是没有看到在这里使用Web服务的优势.

有人可以通过创建两个版本的Web应用程序来测试这一点,无论是否有Web服务,都可以进行压力测试,但我还没有这样做.

您是否对使用小型Web应用程序的Web服务有意见？Web服务不是一个好的架构选择的任何其他场合？

1> Ben Scheirma..：

---

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服务是不负责任的编程.

---

我完全同意.我公司的主项目有一个webapp与一个与持久层交谈的Web服务.除了webapp之外,没有其他任何东西可以访问Web服务.删除Web服务将删除不添加任何值的巨型层.任何地方的改变需要更新3个地方!

2> DOK..：

---

夏洛特的杰出开发人员Nick Harrison建议使用Web服务的这些场景是有道理的:

在Web场中,有多个托管网站的Web服务器,所有Web服务器都指向在另一个Web服务器上运行的Web服务.这允许在多个服务器上分配负载.

客户端/服务器,Windows窗体应用程序可以调用Web服务.

跨平台

穿过防火墙

3> ddimitrov..：

---

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

众多标准可用于详细描述合同的不同方面,而(假设的)完全兼容的WS堆栈可以消除第三方开发人员的许多痛苦,甚至允许传说中的点击集成a'la雅虎管道.通过良好的治理控制,您可以根据需要改进公共接口并管理向后兼容性.

所有这一切几乎不可能自动生成.C#存根生成器只知道类的物理接口,但对所涉及的语义一无所知.有关更详细的讨论,请参阅此文章.

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

Web服务是粗粒度集成解决方案.它们是僵化的,它们比替代品慢,它们需要花费太多精力才能做得好(而且当做得不好时,它们就会毫无意义).

概括地说:"什么时候的网络服务不被使用？" - 任何时候你可以在没有它的情况下离开

4> Jared..：

---

如果您只是为您的Intranet编写一个小的(少于50个用户)Web应用程序,那么Web服务似乎有点过分.特别是如果不使用其主要功能(提供对许多服务的单点访问).