С# HttpWebRequest vs WebRequest
Я видел эту часть кода:
var request = (HttpWebRequest) WebRequest.Create("http://www.google.com");
Зачем вам нужно использовать (HttpWebRequest)
? Почему бы просто не использовать HttpWebRequest.Create
? И почему HttpWebRequest.Create
делает WebRequest
, а не HttpWebRequest
?
Ответы
Ответ 1
Метод Create
является статическим и существует только на WebRequest
. Вызов HttpWebRequest.Create
может выглядеть по-другому, но на самом деле он скомпилирован до вызова WebRequest.Create
. Похоже, что он находится на HttpWebRequest
из-за наследования.
Внутренний метод Create
использует шаблон factory для фактического создания объектов на основе Uri
, который вы передаете ему. Вы могли бы вернуть другие объекты, такие как FtpWebRequest
или FileWebRequest
, в зависимости от Uri
.
Ответ 2
WebRequest
- это абстрактный класс, который имеет метод factory Create
, который, в зависимости от переданного URL, создает экземпляр конкретного подкласса. Нужно ли вам или хотите
HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl);
вместо
WebRequest req = WebRequest.Create(strUrl);
зависит от ваших потребностей и от того, какие URL-адреса вы передаете.
Если вы передаете только HTTP: URL, тогда прежний код позволяет вам получить доступ к свойствам и методам, которые реализует подкласс HttpWebRequest
в дополнение к тем, которые определены в базовом классе WebRequest
. Но если вы перешли по FTP: URL-адрес, попытка сбрасывания на HttpWebRequest
завершится с ошибкой.
Последний является общим и не будет терпеть неудачу на любом из типов поддерживаемых URL-адресов, но, конечно, без использования какого-либо подкласса вы можете получить доступ только к свойствам и методам, которые определяет базовый класс.
- через Мартина Хоннен
Ответ 3
Приведение в действие необходимо только тогда, когда вам нужен доступ к элементам, уникальным для HttpWebRequest. Идея состоит в том, что если свойств/методов, поддерживаемых в WebRequest, достаточно, вы можете написать приложение, которое будет работать против многих типов протоколов запроса/ответа. В этом случае URI может быть чем-то заданным пользователем, используя любой протокол, поддерживаемый подключаемыми протоколами. Новые протоколы могут поддерживаться без изменения исходного программного обеспечения.
Если вашему приложению требуется больше контроля над особенностями, относящимися к определенному протоколу, вы можете ограничить requestUri вашей поддерживаемой схемой (-ами) и бросить WebRequest в соответствующий подклассу определенного протокола. Это ограничивает протоколы, поддерживаемые вашим приложением, но позволяет вам настраивать специфические для протокола функции.