为什么 MVC 基类的实现与 WebForms 截然不同？

Question

长期以来，我需要问一个不应该但取悦于人类头脑的问题。

为什么 MVC 对服务器、响应等的实现与 WebForms 不同？

在 MVC 中取决于：

• MVC 会话 HttpSessionStateBase -> 来自 System.Web

• MVC 服务器 HttpServerUtilityBase

• MVC 请求 HttpRequestBase

• MVC 响应 HttpResponseBase

• MVC 上下文 HttpContextBase

但是在 WebForms 中：

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

• HttpServerUtility

• HTTP请求

• HTTP响应

• Http上下文

同样在 MVC 中，HttpContext 是控制器的一个属性。但在 WebForms 中，HttpContext 只是一个静态类。

看起来像 MVC 为 WebForms 放置了 Wrappers 类？或者我不知道。

HttpSessionStateWrapper

HttpContextWrapper

我只是想知道为什么所有这些东西都不一样？编写库的专家是否使它们看起来不错而不是丑陋？

Answer 1

长话短说MVC确实使用HttpRequest, HttpContext,HttpResponse等。它只是不直接使用它们。通过依赖于“基”类，它允许您替换从那些抽象类继承的您自己的实现。这使我们能够为控制器或其他依赖于上下文、请求等的类编写单元测试。在运行时，它获取HttpRequest并将其包装在一个名为的类中，该类HttpRequestWrapper也继承自HttpRequestBase，因为HttpRequest不继承自HttpRequestBase。（和其他类的相同模式。）从技术上讲，MVC 在运行时使用与 WebForms 相同的类。它只是不直接依赖于它们。相反，它取决于基类。在运行时，它使用类似HttpContextWrapper从基类继承的包装类，但实际上“包装”了 , 等的HttpContext实例HttpRequest。通过依赖抽象类HttpContextBase而不是具体类HttpContext，MVC 框架使您能够通过提供抽象类的替代实现来“模拟”这些类。这是一个流行的答案。这不是很简单，但至少不是不可能。相比之下，使用 WebForms 进行单元测试要困难得多。WebForms 的大部分测试策略都涉及尽可能多地远离它们并将其放在其他可测试的类中。但是当涉及到请求、响应、上下文等任何事情时，就很难了。显然这并非不可能，但您必须在页面中做一些奇怪的自定义内容，而不是使用Context或Page属性。