我们是否应该在Asp.Net应用程序中创建由应用程序本身调用的本地web服务？

我已经转移到一个新的项目团队，在查看代码库时，发现团队已经创建了许多本地web服务，这些服务随后被同一应用程序中其他web页面中的服务器代码调用

我对这种体系结构有些困惑，因为我认为本地web服务是可以从客户端或其他不同的应用程序访问的

然而，通过从应用程序中的其他服务器代码与本地web服务通信，我认为我们正在经历将消息包装成XML/Soap并通过html堆栈发送到服务，然后再返回的繁琐过程，最终会增加大量时间并降低应用程序的速度

我已经向我的新同事们提到了我对此的担忧，并且有一些争论。我只是想知道其他人对这种方法的看法，我的担心是否正确

谢谢

---

Mickey

即使目前只有一个客户端调用了yoru web服务，将来可能还会有其他客户端。从这个角度来看，我更关心的是应用程序分区在架构上是否有意义。也就是说，这是一种良好的关注点分离吗？当然，性能是另一个考虑因素。

使用本地web服务不是一件坏事。它可以增加给定应用程序的模块化（增加内聚，减少耦合）。将目标代码移动到web服务中可以被看作是创建共享库（DLL、.so等），其重要优点是可以轻松地从不同进程调用。这就像用RPC或DCOM来减轻头痛一样。只要保持调用约定的清晰，创建几乎完全由web服务调用组成的应用程序就不会有问题。这是mashup的应用程序版本。

我认为您对团队将在应用程序中实现web服务调用感到有点惊讶是正确的-为什么要支付开销

然而，真正的问题不一定是web服务调用——这是一种合法的技术。更大的问题可能是你的职责分工。web服务处理程序类似于标准页面中的UI：用于处理与外部世界的交互。它应该将接收到的参数传递给业务逻辑对象

---

单独的业务逻辑对象的优点是多方面的：更容易的单元测试和从代码中直接调用同一函数的能力是最突出的。因此，他们可能应该将逻辑从web服务重构为业务逻辑对象，并直接调用该对象，而不是产生web服务调用的开销。

非常感谢，我看不出有必要增加开销，这正是我所关心的，因为我们很快就会扩大规模。我被告知不会有开销，也看不出为什么不会，所以在这个问题上获得一致意见是件好事。你的观点是，业务逻辑和单元测试也是有效的，谢谢，因为我们没有单独的业务逻辑层，也没有进行单元测试。Mickey，业务层和单元测试的好处是，你可以从小事做起——只需在那里添加新功能，并在可能的情况下将所有其他功能分块迁移。我几乎可以肯定地告诉您，如果您的团队采用TDD流程，您的整个流程将更好更快。我真的无法想象任何发展挑战在哪里都不是优势。