从一开始我就需要提出一个不应该问的问题，但请在人头上讨好它的问题。
为什么MVC对WebForms的服务器，响应等有不同的实现？
在MVC中取决于：
但是在WebForms中：
同样在MVC中，HttpContext是控制器的属性。但是在WebForms中，HttpContext只是一个静态类。
看起来MVC为Web Forms提供了Wrappers类吗？或者我不知道。
HttpSessionStateWrapper
HttpContextWrapper
我只是想知道为什么所有这些都不同？编写库的专家是否会像这样看起来好看而不丑？
TL; DR
MVC确实使用HttpRequest，HttpContext，HttpResponse等。它只是不直接使用它们。
通过依赖“基础”类，它允许您替换从这些抽象类继承的您自己的实现。这使我们能够为依赖于上下文，请求等的控制器或其他类编写单元测试。
在运行时它需要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属性。