网络服务VS. Aspx页面:优点和缺点

Question

我们开发了一个托管在内部网络上的ASP.Net Web应用程序.目前,我们有一些ASPX页面可以处理来自客户端的Web请求并与我们的服务器进行交互.我们正在开始开发下一个主要的应用程序版本,我们正在决定架构.

与使用完整的Web服务(很可能是WCF服务)相比,使用ASPX页面处理http请求有什么区别？

在研究这个问题时,我发现了一些相关的帖子,这些帖子在这里和这里都是适度的.我对一些主要差异的理解如下:

1. ASPX页面受限于它们可以接收的请求类型.它们是严格的HTTP,而WCF服务可以有多个端点来服务各种协议(HTTP,TCP等).
2. 由于ServiceContracts,更具体地定义了WCF服务.这意味着如果项目引用了该服务,他们就会确切地知道在方法,用法和文档方面会有什么期望.在包含的方法和接受的请求方面,ASPX页面对所有人来说都是免费的.

但是,基于这些概念,我的问题如下:

1. 支持不同协议的能力是未来验证和兼容性方面的一个很好的特性,但是如果我们目前只使用它通过HTTP进行交互,我们会看到真正的好处吗？
2. 根据我之前的观点,如果我们只是通过网络与服务进行交互,那么这些点中的任何一点真的会有所不同吗？只要它所称的方法"正常工作",http请求就不关心任何更精细的细节或合同保证.

有什么我想念的吗？使用服务的任何关键好处？就个人而言,我支持Web服务架构.我喜欢拥有一个可以支持未来发展的灵活且定义明确的系统的想法.我基本上想要摆脱这个是一种方式去同事说"这应该是一个服务的xyz原因,我们可以看到abc改进这样做".

Answer 1

WCF（以及较旧的基于 asmx 的 Web 服务）为您完成了很多序列化任务。您可以从方法返回对象，框架会将这些对象序列化为正确格式的 XML 并为客户端提供 wsdl，以便他们可以调用您的 Web 服务方法并了解他们返回的内容。

你可以用网页做网页（我打赌有PHP的“网络服务”在那里负载），但你必须自己做这一切的管道。

请求事物的类型是 WCF-magic。WCF 具有“端点”的概念，它允许您将调用服务的方法与服务所做的事情分开。它只是一个更好的（尽管很多事情非常复杂）架构，可以更好地将这两个问题分开。

我怀疑使用 asmx 而不是 WCF 是任何 Web 服务的性能瓶颈。Web 服务架构中的性能损失几乎总是由于繁琐的接口和/或非常大的对象/对象图。在大多数情况下，您对 Web 服务进行远程调用这一事实使得 WCF 与 asmx 的速度差异无关紧要。WCF 在设计上更加灵活，这是选择它的正当理由。WCF 确实使用了DataContractSerializeraxms中使用的较新的方法而不是较旧的方法，并且据说它要快一些。我认为您必须扩展到相当多的用户才能看到有意义的差异 - 您最好先寻找健谈的界面和性能不佳的数据库查询。

当然，如果有疑问 - 首先衡量，然后针对表现不佳的特定领域。

Answer 2

您不应该像在PHP世界中经常看到的那样，将ASPX页面用作即兴服务端点。对ASPX页面的请求通过相当多的HttpModule进行过滤，这对于简单服务终结点来说是不必要的开销，并且每个请求无缘无故地创建Page类的实例。

如果您需要的只是一个非常简单的终结点，可以使用XML或JSON进行响应，那么ASMX仍然是一个不错的选择。

如果您需要更大的灵活性并且愿意处理配置负担，则WCF非常强大。

另一个经常被忽略的选择是使用HttpHandler。将ASHX HttpHandler组合在一起是相对简单/容易的，它使您对请求/响应的访问非常“接近金属”，而开销却比ASPX页少得多。