我搬到了一个新的项目团队，在查看代码库时，发现团队已经创建了许多本地 Web 服务，然后由同一应用程序中其他网页中的服务器代码调用。
我对这种架构有些困惑，因为我认为本地 Web 服务是您可以从客户端或其他不同应用程序访问的东西。
但是，通过从我们应用程序中的其他服务器代码与本地 Web 服务进行通信，在我看来，我们正在经历将消息包装到 XML/Soap 中并通过 html 堆栈到服务然后再返回的复杂过程最终会增加大量时间并减慢应用程序的速度。
已经向我的新同事提到了我对此的担忧，并且有一些争论。只是想知道其他人对这种方法的看法，我是否应该担心？
谢谢
米奇
使用本地 Web 服务并不是一件坏事。它可以增加给定应用程序的模块化（增加内聚，减少耦合）。将目标代码移动到 Web 服务中可以被认为是创建一个共享库（DLL、.so 等），其重要优点是可以轻松地从不同进程中调用。这就像使用 RPC 或 DCOM 来减少头痛一样。只要您保持调用约定清晰，创建几乎完全由 Web 服务调用组成的应用程序应该不成问题。它是 Mash-ups 的应用程序版本。
尽管 yoru Web 服务目前被 1 个客户端调用，但将来可能还会有其他客户端。从这个角度来看，我会更关心应用程序分区在架构上是否有意义。也就是说，这是一个很好的关注点分离吗？当然，性能是另一个考虑因素。
我认为您对团队会在应用程序中实现 Web 服务调用感到有点惊讶是正确的——为什么要支付开销？
然而，真正的问题不一定是网络服务调用——这是一种合法的技术。更大的问题可能在于你的职责分工。Web 服务处理程序类似于标准页面中的 UI：用于处理与外部世界的交互。它应该将接收到的参数传递给业务逻辑对象。
单独的业务逻辑对象的优点是多方面的：更容易的单元测试和从代码中直接调用相同函数的能力是最突出的。因此，他们可能应该将 Web 服务中的逻辑重构为业务逻辑对象并直接调用该对象，而不是产生 Web 服务调用的开销。