Web API oData - 我應該忘記視圖模型嗎？

我一直在使用MVC一段時間，並用於爲每個MVC視圖創建一個View Model類。現在我正在嘗試Web API，我想我可能會掛在這個MVC心態上。我的關係是這樣的：Web API oData - 我應該忘記視圖模型嗎？

public class Supplier 
{ 
    public int Id { get; set; } 
    public string Title { get; set; } 

    public virtual ICollection<SupplierProduct> SupplierProducts { get; set; } 
} 

public class Product 
{ 
    public int Id { get; set; } 
    public string Title { get; set; } 

    public virtual ICollection<SupplierProduct> SupplierProducts { get; set; } 
} 

public class SupplierProduct 
{ 
    public int Id { get; set; } 
    public string Title { get; set; } 

    public int SupplierId { get; set; } 
    public virtual Supplier Supplier { get; set; } 

    public int ProductId { get; set; } 
    public virtual Product Product { get; set; } 
}

我在創作的供應商，其中在創建形成用戶的工作能夠選擇已經存在的多種產品。在MVC中，我會後，看起來像這樣的視圖模型：

public class SupplierCreateViewModel 
{ 
    public string Title { get; set; } 
    public ICollection<ProductViewModel> SelectedProducts { get; set; } 
}

和Controller我會首先創建新的供應商，然後爲每個SelectedProduct新SupplierProduct。我在供應商oData控制器的POST操作中在Web API中實現了這樣的事情，但它感覺不對。我認爲，相反，我需要改變我的方法，並從客戶端做這樣的事情：

廢棄視圖模型設計。（無論如何，還沒有真正的'視圖'）
同時對供應商和供應商產品控制器都採用POST操作。
保存時，請發送我的供應商創建請求到POST api/Suppliers/。
在響應中使用供應商JSON的Id，發送多個創建請求到POST api/SupplierProduct。

所以我的問題是：

我在正確的方向用這種方法去？
而不是查看模型是否有我應該使用的不同模式？ DTO？
在給出的例子中，我是否被迫發送1 - n個請求？這感覺不對。

來源

2015-11-01 Jonathan Eckman

其實它取決於你的用例。如果你的API完全面對公衆，我會建議使用DTO的。如果是yourselve或內部的團隊，我會的OData EF模型棒（因爲它的速度更快）

可以（像往常一樣）通過自己的API給整個實體。
您可以使用viewmodel（更像是在API中使用它時的DTO，但它是一樣的）並相應地轉換方法。您可以使用automapper - 它也轉換$ filter查詢，在這裏找到一個示例：Web API Queryable - how to apply AutoMapper?。

不要忘了，API有很多很棒的優點。 OData使用批次和修補程序來更改您的實體。所以我個人堅持Odata作爲大部分時間的邀請，但這是個人選擇。

來源

2015-11-01 23:56:04 NicoJuicy

Web API oData - 我應該忘記視圖模型嗎？

回答

相關問題