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

【问题标题】：Should we create local web services within an Asp.Net application which are called by the application itself?我们是否应该在应用程序本身调用的 Asp.Net 应用程序中创建本地 Web 服务？
【发布时间】：2010-12-14 17:45:18
【问题描述】：

我搬到了一个新的项目团队，在检查代码库时，发现团队创建了许多本地 Web 服务，然后由同一应用程序中其他网页中的服务器代码调用。

我对这种架构有些困惑，因为我认为本地 Web 服务是您可以从客户端或其他不同应用程序访问的东西。

但是，通过我们应用程序中的其他服务器代码与本地 Web 服务进行通信，在我看来，我们正在经历将消息包装到 XML/Soap 并通过 html 堆栈到服务然后返回的复杂过程再次，最终会增加大量时间并减慢应用程序的速度。

已向我的新同事提到了我对此的担忧，并引起了一些争论。只是想知道其他人对这种方法的看法是什么，我是否应该担心？

谢谢

米奇

【问题讨论】：

标签： asp.net architecture service local

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

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

【讨论】：

非常感谢马克，我看不出需要开销，这就是我担心的问题，因为我们很快就会扩大规模。有人告诉我，不会有开销，也看不出为什么不，所以很高兴能就此达成一致。您的观点是业务逻辑和单元测试也是有效的，谢谢，因为我们没有单独的业务逻辑层，也没有进行单元测试。
Mickey，业务层和单元测试的好处在于您可以从小处着手——只需将新功能放在那里，并在可能的情况下将其他所有内容迁移。我几乎可以肯定地告诉您，如果您的团队采用 TDD 流程，您的整个流程将会更好更快。我真的无法想象任何没有优势的开发挑战。