TL; DR
MVC делает использование HttpRequest, HttpContext, HttpResponse и т. Д. Он просто не использует их напрямую .
В зависимости от «базовых» классов это позволяет вам заменять ваши собственные реализации, которые наследуются от этих абстрактных классов.Это позволяет нам писать модульные тесты для контроллеров или других классов, которые зависят от контекста, запроса и т. Д.
Во время выполнения он занимает HttpRequest и упаковывает его в класс с именем HttpRequestWrapperкоторый также наследуется от HttpRequestBase, поскольку HttpRequest не наследуется от HttpRequestBase.(И тот же шаблон для других классов.)
Технически MVC использует те же классы, что и WebForms во время выполнения.Это просто напрямую не зависит от них.Вместо этого это зависит от базовых классов.Во время выполнения он использует классы-оболочки, такие как HttpContextWrapper, которые наследуются от базового класса, но на самом деле "обертывают" экземпляр HttpContext, HttpRequest и т. Д.
В зависимости от абстрактных классов, таких как HttpContextBaseв конкретных классах, таких как HttpContext, инфраструктура MVC позволяет «макетировать» эти классы, предоставляя альтернативные реализации абстрактных классов. Вот популярный ответ на это.Это не очень просто, но, по крайней мере, не невозможно.
В отличие от модульного тестирования было гораздо сложнее с WebForms.Большая часть стратегии тестирования для WebForms заключалась в том, чтобы сохранить как можно больше от них и поместить их в другие тестируемые классы.Но когда дело касалось чего-либо, связанного с запросом, ответом, контекстом и т. Д., Это было сложно.Очевидно, что не было невозможно , но вы должны были сделать некоторые странные пользовательские вещи на своих страницах вместо использования свойств Context или Page.