C # HttpWebRequest vs WebRequest
J'ai vu ce morceau de code:
var request = (HttpWebRequest) WebRequest.Create("http://www.google.com");
Pourquoi avez-vous besoin de lancer (HttpWebRequest)? Pourquoi ne pas simplement utiliser HttpWebRequest.Create? Et pourquoi HttpWebRequest.Create faire un WebRequest, pas un HttpWebRequest?
La méthode Create est statique et n'existe que sur WebRequest. L'appeler comme HttpWebRequest.Create peut sembler différent, mais sa compilation est en fait appelée à appeler WebRequest.Create. Il semble que ce soit uniquement sur HttpWebRequest à cause de l'héritage.
La méthode Create en interne utilise le modèle d'usine pour créer les objets, en fonction du Uri que vous lui transmettez. Vous pourriez en fait récupérer d’autres objets, tels que FtpWebRequest ou FileWebRequest, en fonction de Uri.
WebRequest est une classe abstraite qui a une méthode fabrique Create qui, en fonction de l'URL transmise, crée une instance d'une sous-classe concrète. Que vous ayez besoin de ou que vous souhaitiez HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl); au lieu de WebRequest req = WebRequest.Create(strUrl); dépend de vos besoins et du type d'URL que vous transmettez.
Si vous ne transmettez que les HTTP: URL, l'ancien code vous permet d'accéder aux propriétés et aux méthodes que la sous-classe HttpWebRequest implémente en plus de celles définies dans la classe de base WebRequest. Mais si vous avez passé une adresse FTP: URL, la tentative de conversion vers HttpWebRequest échouera.
Ce dernier est générique et n'échouera pas sur aucun des types d'URL pris en charge. Bien entendu, sans attribution à une sous-classe, vous ne pouvez accéder qu'aux propriétés et méthodes définies par la classe de base.
- via Martin Honnen
La distribution n'est nécessaire que lorsque vous avez besoin d'accéder à des membres uniques à HttpWebRequest. L'idée est que si les propriétés/méthodes prises en charge sur WebRequest sont suffisantes, vous pouvez alors écrire une application qui fonctionnera avec de nombreux types de protocoles de requête/réponse. Dans ce cas, l'URI peut être donné par l'utilisateur en utilisant n'importe quel protocole pris en charge par des protocoles enfichables. De nouveaux protocoles peuvent même être pris en charge sans modifier le logiciel d'origine.
Si votre application a besoin de davantage de contrôle sur les fonctionnalités spécifiques à un protocole particulier, vous pouvez limiter requestUri aux schémas que vous prenez en charge et convertir WebRequest dans la sous-classe appropriée spécifique au protocole. Cela limite les protocoles pris en charge par votre application, mais vous permet de modifier les fonctionnalités propres au protocole.