2012-06-22 35 views
5

Tôi nhận được những gì tôi coi là một vấn đề ràng buộc lạ trong ASP.NET MVC 4 RC Web API. Tôi có một phương pháp nhằm chấp nhận các yêu cầu đăng bài từ khách hàng. Vấn đề là không có tham số nào ràng buộc khi phương thức post được gọi, tôi nhận được điểm break của mình trên dòng và tên, email đều là null. Nếu tôi thay đổi kiểu yêu cầu GET trong JavaScript, thì hàm Get bên dưới được gọi với các tham số bị ràng buộc.ASP.NET MVC 4 RC Web API Tham số Binding vấn đề

Tại sao các tham số không ràng buộc cho phương thức Đăng và cách tôi có thể sửa lỗi này?

send: function(evt) { 
    evt.preventDefault(); 
    $.ajax({ 
     url: '/api/person', 
     data: this.model.toJSON(), 
     type: "POST", 
     dataType: "json", 
     success: function(data) { 
      console.log("Success"); 
     }, 
     error: function(data) { 
      console.log("Error"); 
     } 
    }); 
    } 

Sau đây là những hành động điều khiển:

public void Get(string name, string email) { 
    throw new NotImplementedException(); 
} 

public void Post(string name, string email) { 
    throw new NotImplementedException(); 
} 

Ghi chú:

  • Tôi đang sử dụng tất cả các giá trị mặc định cho ASP.NET MVC 4 RC Web API (Vì vậy, các deserializer nên là Json.NET)
  • Tab mạng Chrome trên trình gỡ lỗi JS hiển thị các thông số trong dữ liệu biểu mẫu trên bài đăng chính xác.

Trả lời

13

Không giống như MVC (trang web), các loại thông số đơn giản will not, by default, bind from the post body but instead from the URI. Vì vậy, với mã của bạn như-là bạn sẽ cần phải vượt qua các tham số nameemail trong chuỗi truy vấn hoặc dưới dạng tham số tuyến đường.

Tuy nhiên điều này có thể dễ dàng được giải quyết bằng cách tạo kiểu mô hình (trong MVC tiếng địa phương) và sử dụng nó cho các tham số phương pháp. Trong thực tế thì bạn có thể sử dụng nó cho cả hai (trong trường hợp bạn đã đưa ra), nếu bạn sau đó sử dụng [FromUri] vào phương pháp get:

public class SomeParams { 
    public string name { get; set; } 
    public string email { get; set; } 
} 

//now an alternative way to write the Get method 
public MyResult Get([FromUri] SomeParams p){ 
    //members are bound from the query string (more like MVC traditional binding) 
    //note - as in MVC, SomeParams will need a default constructor for this to work. 
} 

public PostResult Post(SomeParams p){ 
    //'p' is bound from your JSON (assuming correct format) 
    //because 'complex' types are deserialized using formatters 
    //only one object can be read from the body with a formatter in Web API 
    //as the request body is not buffered; unlike MVC. 
} 

Tôi đã bị mắc kẹt trong các loại để đổi lấy những phương pháp chỉ vì họ sẽ cần phải trả lại một cái gì đó!

Tôi thực sự khuyên bạn nên đọc qua bài viết của Mike Stall mà tôi liên kết ở trên (và nhiều người khác của anh ấy).

Thật hấp dẫn để giả định rằng Web API, bởi vì nó chia sẻ cùng một mô hình và thậm chí cả tên lớp của MVC, thực sự giống như MVC - nhưng không phải. Tôi tự hỏi ban đầu vì sao đây là trường hợp (vì tôi đã viết rất nhiều dịch vụ REST trên bản thân MVC và thấy nó khá thú vị, một khi bạn đã viết một vài lớp tiện ích và các cải tiến cơ sở), nhưng họ đã xem xét kỹ các thách thức của việc viết một API web và tôi nghĩ có lẽ đã đúng khi thực hiện các thay đổi trong cách tiếp cận mà họ có.

Tuy nhiên, điều đó có nghĩa là chúng tôi phải thực hiện một vài điều mà hiện tại chúng tôi có thể lấy và cấp lại cho API Web.

+0

Thông số nhận của tôi không bị vô hiệu, thực tế nó không tồn tại. Tôi có thể không rõ ràng nhưng nó chỉ ở đó để minh họa rằng chức năng hoạt động trên GET và không có trên POST. – Cody

+1

Được rồi - tốt, vậy thì tốt :). Trong ngắn hạn, mặc dù, nếu bạn đang ràng buộc nhiều thông số từ cơ thể của yêu cầu, về cơ bản điều dễ nhất để làm là viết một kiểu mô hình đơn giản như tôi đã hiển thị. –

+0

Cảm ơn bạn đã liên kết bài viết Mike Stall, nó rất thông tin về những gì đang diễn ra. Tôi vừa cho rằng Web API đã sử dụng cùng một chiến lược ràng buộc giống như MVC. Tạo một lớp tùy chỉnh để nhận được các params làm việc như một sự quyến rũ, tôi không phải là một fan hâm mộ của giải pháp đó nhưng tôi không thể tìm ra lý do tại sao, vì vậy tôi có lẽ chỉ là cứng đầu. :) Trong mọi trường hợp, đó là giải pháp tôi sẽ sử dụng. Cảm ơn!:) – Cody

Các vấn đề liên quan