asp.net-mvc - 在 Webapi 中拥有 ViewModel 有意义吗？

Question

我开始学习 webapi，发现自己正在做一些在 MVC 项目中有意义但在其他项目中可能没有意义的事情。

通常在 MVC 项目中，我创建 ViewModel 并将其用作参数或将它们与 View 一起传回。

由于 webapi 中没有 View ，我想将 ViewModel 作为参数是没有意义的。

我想知道是否应该将我的 EF 域(代码优先)作为参数，然后将数据注释放在这些域之上。我通常会将注释放在 View 模型属性上，因为我喜欢在域上这样做。

然而，阻止我这样做的是我并不是 100% 清楚我的 MVC 网站将如何工作。

MVC 站点是否只是返回简单 View ，然后使用 Jquery 调用 Webapi，还是只调用 MVC 操作方法，直接调用 Webapi 会调用的相同方法？

如果是第二种方式，那么我宁愿再次将数据注释放在我的 View 模型上，但随后我将相同的注释放在 EF 域和 VM 上，这似乎是多余的。

Answer 1

在使用这个“东西”很长时间之后我的建议:

BindingModels 用于数据绑定(bind)(mvc 或 api)

ViewModels 用于 mvc 上的 View (您的 api 中可能有一些 mvc 页面，因此最好有一个放置此内容的位置，可以是文档、介绍页面等。如果没有 View ，那么您可以拥有零个 ViewModel)这样做的好处之一是您可以在 Views/web.config 中拥有 ViewModels 命名空间引用，并且它不会被您的 api 资源污染。

ResourceModel 用于 Web API 资源。在 webapi 中，嵌套资源也是可以到达树中任何位置的资源，这在 mvc 上并不常见，因此将它们命名为资源很有意义。

如果您想接收资源，您可以使用您的资源模型。请记住，您收到的信息与您发回的信息相同。

如果您想要自定义输入绑定(bind)(这应该是您的默认场景)，您就有自己的绑定(bind)模型。

如果您有任何 mvc View ，出于管理目的、文档等，请使用您的 ViewModel。

如果您在 mvc 上有表单页面，则也可以在 POST Controller 上使用 BindingModel。 MVC 或 WEBAPI 上的帖子不需要有不同的模型。特别是当模型绑定(bind)器或格式化程序都可以使用相同的数据注释理解并映射到相同的绑定(bind)模型时。

有时，您想要创建带有资源和一些额外字段的绑定(bind)模型。继承是你的 friend 。

有时您希望使用多个资源和(可选的额外字段)创建绑定(bind)模型，资源作为属性是您的 friend 。

在 MVC 世界中，您还可以使用“资源”的概念，但它不太常见。当您在同一个项目中使用 MVC 和 Web Api 时，这会派上用场。

如果您需要对任何项目(如文件夹结构、命名空间等)进行进一步评论，请告诉我。我非常乐意分享我的优缺点经验。

哦，我忘了，映射策略值得研究。我个人会做自己的映射，但是将这个逻辑放在一个地方是无价的。

编辑:非常幼稚的例子

ContactViewModel{

    string Name {get;}
    string LastName {get;}
    List<Country> AvailableCountries {get;}
    Country Country {get;}
    bool IsAdmin {get;}

}

ContactBindingModel{

    string Name {get;set;}
    string LastName {get;set;}
    int Country {get;set;}

}

ContactResourceModel{

    string Name { get;set;}
    string LastName {get;set;}
    Country Country {get;set;}
    string IsAdmin {get;}

}