C # HttpWebRequest so với WebRequest

112

Tôi thấy đoạn mã này:

var request = (HttpWebRequest) WebRequest.Create("http://www.google.com");

Tại sao bạn cần phải cast (HttpWebRequest)? Tại sao không chỉ sử dụng HttpWebRequest.Create? Và tại sao lại HttpWebRequest.Createtạo ra a WebRequest, không phải a HttpWebRequest?

c# httpwebrequest

— không xác định
nguồn

bài liên quan: stackoverflow.com/q/8209781/274502

— cregox

Câu trả lời:

134

Các Createphương pháp là tĩnh, và chỉ tồn tại trên WebRequest. Gọi nó HttpWebRequest.Createcó thể trông khác, nhưng nó thực sự được tổng hợp lại để gọi WebRequest.Create. Nó chỉ xuất hiện HttpWebRequestvì kế thừa.

Các Createphương pháp nội bộ, sử dụng các mô hình nhà máy để làm việc tạo ra thực tế của các đối tượng, dựa trên các Uribạn vượt qua vào nó. Bạn thực sự có thể lấy lại các đối tượng khác, như một FtpWebRequesthoặc FileWebRequest, tùy thuộc vào Uri.

— David Wengier
nguồn

Đúng rồi đó. Sẽ thật tuyệt nếu có một cách để lấy HttpWebRequest từ HttpWebRequest.Create hoặc một cái gì đó như HttpWebRequest.CreateHttp mà không cần truyền. Đầu tiên sẽ là một cái gì đó giống như HttpWebRequest Create tĩnh mới công khai (chuỗi url). Dù bằng cách nào, nếu url không phải là (các) HTTP, thì nó sẽ chỉ ném ra một số InvalidArgumentException.

— Matthew Flaschen

Một lời giải thích rất hay về một quyết định thiết kế rất kỳ lạ (tôi có dám nói sai không?) Của những người sáng tạo .NET.

— IJ Kennedy,

@IJKennedy Tôi hoàn toàn đồng ý, một quyết định thiết kế rất kỳ lạ, phi logic và phi thực tế.

— Aidiakapi

HttpWebRequest.CreateHttp không tồn tại và tạo một phiên bản HttpWebRequest.

— Peter Meinl

@Bobson WebRequest.CreateHttplà 4.5

— Mark

WebRequestlà một lớp trừu tượng, có một phương thức gốc Create, tùy thuộc vào URL được truyền vào, tạo ra một thể hiện của một lớp con cụ thể. Việc bạn cần hay muốn HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl);thay vì WebRequest req = WebRequest.Create(strUrl);tùy thuộc vào nhu cầu của bạn và loại URL bạn chuyển vào.

Nếu bạn chỉ chuyển vào HTTP: URL, thì mã trước đây cho phép bạn truy cập các thuộc tính và phương thức mà lớp con HttpWebRequesttriển khai ngoài những thuộc tính được xác định trên lớp cơ sở WebRequest. Nhưng nếu bạn đã chuyển qua FTP: URL thì nỗ lực truyền tới HttpWebRequestsẽ không thành công.

Cái sau là chung chung và sẽ không bị lỗi đối với bất kỳ loại URL nào được hỗ trợ nhưng tất nhiên nếu không truyền tới bất kỳ lớp con nào, bạn chỉ có thể truy cập các thuộc tính và phương thức mà lớp cơ sở xác định.

- qua Martin Honnen

— Orhan Cinar
nguồn

Diễn viên chỉ cần thiết khi bạn cần quyền truy cập vào các thành viên duy nhất của HttpWebRequest. Ý tưởng là nếu các thuộc tính / phương thức được hỗ trợ trên WebRequest là đủ, thì bạn có thể viết một ứng dụng hoạt động dựa trên nhiều loại giao thức yêu cầu / phản hồi. Trong trường hợp này, URI có thể là thứ do người dùng cung cấp bằng cách sử dụng bất kỳ giao thức nào được hỗ trợ bởi các giao thức có thể cắm được. Các giao thức mới thậm chí có thể được hỗ trợ mà không làm thay đổi phần mềm gốc.

Nếu ứng dụng của bạn cần kiểm soát nhiều hơn đối với các tính năng dành riêng cho một giao thức cụ thể thì bạn có thể hạn chế requestUri đối với (các) lược đồ được hỗ trợ của mình và truyền WebRequest tới lớp con dành riêng cho giao thức thích hợp. Điều này giới hạn các giao thức được ứng dụng của bạn hỗ trợ, nhưng cho phép bạn tinh chỉnh các tính năng dành riêng cho giao thức.

— Kevin
nguồn