Lý do đằng sau ASP.NET MVC ActionResult là một lớp trừu tượng?

Question

Trong ASP.NET MVC, lớp ActionResult, đó là cơ sở cho tất cả các kết quả trả về bởi phương pháp hành động từ một bộ điều khiển, được định nghĩa là một lớp trừu tượng với phương pháp duy nhất (© Microsoft):

public abstract void ExecuteResult(ControllerContext context); 

bạn có thể nghĩ ra bất kỳ lý do cụ thể cho thiết kế này? Cụ thể, nó có vẻ hơi lạ với tôi, rằng

• không có giao diện IActionResult,
• và rằng lớp sẽ không được yêu cầu ở tất cả, nếu có một giao diện như vậy.

Sau khi tất cả, nếu điều này là một giao diện thay vì rằng lớp trừu tượng, thì sẽ không có nhu cầu để mở rộng một lớp cơ sở để tạo ra một mới ActionResult - người ta sẽ chỉ phải thực hiện IActionResult đúng cách. Trong một thế giới, ngôn ngữ err, không có nhiều thừa kế, lợi thế này có vẻ khá quan trọng đối với tôi.

Answer 1

Giao diện tuyệt vời để cho phép một lớp thực hiện nhiều hợp đồng, chẳng hạn như khi bạn biết rằng một loại phải là hai thứ khác nhau. Trong một số trường hợp, điều này có thể khuyến khích tạo một loại có quá nhiều trách nhiệm.

Kết quả hành động có một trách nhiệm duy nhất và dường như không có trường hợp nào bạn cần một đối tượng làm cả kết quả hành động và điều gì đó khác. Ngay cả khi bạn đã làm, nó có thể làm thông qua thành phần. Vì vậy, trong trường hợp này, chúng tôi đã đi với ABS để cho phép chúng tôi linh hoạt hơn sau khi chúng tôi RTM thực hiện các thay đổi nếu cần thiết.

Tuy nhiên, nếu có một trường hợp cụ thể chúng tôi đang chặn trong đó một giao diện sẽ thích hợp hơn, chúng tôi sẽ xem xét nó. Chúng ta luôn có thể làm điều đó sau này theo cách không phá vỡ. Bạn thậm chí có thể tự mình thực hiện bằng cách viết trình chặn hành động của riêng bạn, chỉ yêu cầu bạn triển khai IActionInvoker (một giao diện) và người invoker đó có thể kiểm tra IActionResult của riêng bạn thay vì ActionResult.

Answer 2

Tôi sẽ đoán vì họ đã dự đoán ActionResult để đạt được các phương pháp và thuộc tính trong vòng đời của CTP/beta. Nếu đó là một giao diện, mọi thay đổi đối với IActionResult sẽ phá vỡ mã hiện có. Việc thêm một phương thức khác vào lớp cơ sở trừu tượng sẽ không gây ra bất kỳ vấn đề nào.

Answer 3

Bạn triển khai giao diện và bạn kế thừa từ các lớp trừu tượng.
Đối với tôi đó là sự khác biệt giữa "là một loại" hoặc "hành động như một loại"

Vì C# không hỗ trợ đa thừa kế, bạn buộc phải xác định lớp của mình là ActionResult, thay vì điều gì đó hoạt động như một ActionResult.

So sánh nó với lớp EventArgs. Tại sao nó có ý nghĩa để kế thừa EventArgs thay vì một giao diện IEventArgs. Vâng bởi vì một EventHandler mang một cái gì đó xung quanh loại EventArgs, không phải cái gì đó hoạt động như một lớp EventArgs.

Answer 4

Tôi biết điều này không chính xác những gì bạn đang tìm kiếm nhưng đối với hahas tôi đã mở nguồn MVC3, thay đổi ActionResult thành IActionResult, chạy một vài tìm và thay thế và mọi thứ được xây dựng tốt.

Điều này có nghĩa với tôi rằng ActionResult là lớp trừu tượng vì lý do API. Có lẽ nó đơn giản như đội MVC muốn bạn có thể sử dụng các lĩnh vực hoặc không muốn cung cấp cho mọi người khả năng làm IActionResult điên, ISomething, IMyNuttyThing.

Answer 5

Một kịch bản mà tôi cho rằng IActionResult sẽ giúp ích cho việc tiêm phụ thuộc. Tôi muốn có một bộ điều khiển được chia sẻ giữa SPA và giao diện người dùng dao cạo. Trong cấu hình tôi muốn tự động đặt loại ứng dụng và có bộ điều khiển của tôi

public ActionResult Get(){ 
    var customer = new Customer(); 
    return View(customer); 
} 

Tôi muốn phương pháp Xem cụ thể được xác định trong thời gian chạy dựa trên loại ứng dụng. I E. Json() hoặc ViewResult()

Đối tượng tôi chuyển vào kết quả cho cả hai trường hợp sẽ giống nhau.

Điều đó có hợp lý không? Hoặc là điều này có thể không có IActionResult?