为什么MVC基类的实现与WebForms完全不同？

Question

从那时起，我需要问一个不应该是的问题，但是请把它摆在人类头上。

为什么MVC对WebForms的Server，Respone等具有不同的实现？

在MVC中取决于：

• MVC会话 HttpSessionStateBase ->来自System.Web
• MVC服务器 HttpServerUtilityBase
• MVC请求 HttpRequestBase
• MVC响应 HttpResponseBase
• MVC上下文 HttpContextBase

但是在WebForms中：

• WebForms会话 HttpSessionState ->来自System.Web.SessionState

• HttpServerUtility

• HttpRequest

• HttpResponse

• HttpContext

在MVC中，HttpContext也是控制器的属性。但是在WebForms中，HttpContext只是那里的静态类。

像MVC一样，将Wrappers类用于WebForms吗？或无知。

HttpSessionStateWrapper

HttpContextWrapper

我只是想知道为什么所有这些都不一样？编写库的专家使这些库看起来不错而不难看吗？

Answer 1

TL; DR

MVC 确实使用HttpRequest，HttpContext，HttpResponse等。它只是不直接使用。 / p>

根据“基”类，它允许您替换从那些抽象类继承的自己的实现。这使我们能够为依赖于上下文，请求等的控制器或其他类编写单元测试。

在运行时，它需要HttpRequest并将其包装到一个名为HttpRequestWrapper的类中，该类也从HttpRequestBase继承，因为HttpRequest并不从HttpRequestBase继承。 （其他类的模式相同。）

---

从技术上讲，MVC在运行时使用与WebForms相同的类。它只是直接不依赖于它们。相反，它取决于基类。在运行时，它使用诸如HttpContextWrapper之类的包装类，这些包装类继承自基类，但实际上“包装”了HttpContext，HttpRequest等的实例。

通过依赖HttpContextBase之类的抽象类而不是HttpContext之类的具体类，MVC框架使您能够通过提供抽象类的替代实现来“模拟”那些类。 Here's a popular answer。这不是很简单，但至少不是不可能。

相比之下，使用WebForms进行单元测试要困难得多。 WebForms的大多数测试策略都涉及尽可能地将它们排除在外，并将其放在其他可测试的类中。但是，当涉及到涉及请求，响应，上下文等的任何内容时，这都很困难。显然是wasn't impossible，但是您必须在页面中做一些奇怪的自定义内容，而不是使用Context或Page属性。