Question

我已经使用MVC一段时间了，我习惯为每个MVC视图创建一个View Model类。现在我正在尝试使用Web API，我想我可能会对这种MVC心态感到不满。我的关系看起来像这样：

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中，我会POST一个看起来像这样的视图模型：

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

在控制器中，我首先创建新的供应商，然后为每个SelectedProduct创建一个新的SupplierProduct。我在我的供应商oData控制器的POST操作中在Web API中实现了类似的功能，但它感觉不对。我认为相反，我需要改变我的方法，并从客户端做这样的事情：

废弃视图模型设计。（不管怎么说，还没有真正的观点）
同时为供应商和SupplierProduct控制器提供POST操作。
保存时，将我的供应商创建请求发送至POST api/Suppliers/。
在回复中使用供应商JSON的ID，向POST api/SupplierProduct发送多个创建请求。

所以我的问题是：

我是否采用这种方法朝着正确的方向前进？
我应该使用不同的模式而不是View Models吗？ DTO？
根据给出的例子，我是否被迫发送1-n这样的请求？这感觉不对。

Answer 1

实际上，这取决于您的用例。如果您的API完全公开面对，我建议使用DTO。如果是为你的十二人或内部团队，我会坚持使用OData EF模型（因为它更快）

您可以（像往常一样）通过您的api给整个实体。
您可以使用viewmodel（在API中使用它时更像DTO，但它是相同的）并相应地转换方法。您可以使用automapper - 它还会转换$ filter查询，例如：Web API Queryable - how to apply AutoMapper?。

不要忘记，API有很多很棒的优点。 OData使用Batch和Patch来更改您的实体。所以我个人大部分时间都坚持使用Odata，但这是个人选择。

Web API oData - 我应该忘记视图模型吗？

1 个答案: