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

Does it Make Sense to have ViewModels in the Webapi?

提问by chobo2

I am starting to learn the webapi and find myself doing stuff that makes sense in an MVC project but may not make sense in.

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

Normally in an MVC project I make ViewModels and use that as the parameter or pass them back with the view.

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

Since there are no views in webapi I guess it does not make sense to have a ViewModel as parameter.

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

I am wondering maybe if I should just have as a Parameter my EF domains(code first) and put data annotations on top of these. I normally would put the annotations over the view model properties as I liked this over the domain.

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

However what is stopping me from doing this is I am not 100% clear how my MVC site would work.

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

Does the MVC site just spit back simples views and then you use Jquery to call your webapi or do you just call MVC action methods that directly just call the same methods the Webapi would call?

MVC 站点是否只是回吐简单的视图，然后您使用 Jquery 来调用您的 webapi 还是您只是调用直接调用 Webapi 将调用的相同方法的 MVC 操作方法？

If is the second way then I rather put the data annotations on my view model again but then I am putting the same ones on both the EF domain and VM's and that seem redundant.

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

采纳答案by Nick Albrecht

Terminology aside, having models for binding to is still of use. They just aren't technically ViewModels anymore, in that you're right there are no views involved. But they are definitely still of use. Using them allows you to take advantage of attributes on your Model's properties and allows you to reuse them across your API if needed. Also remember if you use your entities directly WebAPI will model bind all parameters to them that match by name, even if you didn't mean to.

撇开术语不谈，仍然可以使用绑定到的模型。从技术上讲，它们不再是 ViewModel，因为您是对的，不涉及任何视图。但它们肯定仍然有用。使用它们可以让您利用模型属性上的特性，并允许您在需要时在 API 中重用它们。还请记住，如果您直接使用您的实体，WebAPI 会将所有参数建模绑定到它们，即使您不是故意的。

Also, the Entity Models are representations of your raw data, but the Models used for binding against are a fixed contract that the API requests need to satisfy to successfully process a request. The values in which, could end up spanning multiple entity models by the time your implementation is done, and not be persisted to a data store at all.

此外，实体模型是原始数据的表示，但用于绑定的模型是 API 请求成功处理请求需要满足的固定合同。在您的实现完成时，其中的值可能最终跨越多个实体模型，并且根本不会持久化到数据存储中。

回答by Bart Calixto

My suggestion after loooong time working with this 'things':

我在处理这个“事情”后的建议：

BindingModelsfor data binding (mvc or api)

用于数据绑定的BindingModels（mvc 或 api）

ViewModelsfor views on mvc (you may have some mvc pages inside your api, so it's good to have a place for this, this can be documentation, intro page, whatever. If there is none view, then you can have zero ViewModels) One benefit of this is that you can in your Views/web.config have the ViewModels namespace reference and it won't be polluted with your api resources.

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

ResourceModelfor web api resources. In webapi, nested resources are also resources that go anywhere in a tree which is not that common on mvc, so naming them resources make a lot of sense.

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

If you want to receive a resource, you can use your resource model. Remember your are receiving the same your are sending back.

如果你想接收一个资源，你可以使用你的资源模型。记住你收到的和你发回的一样。

If you want a custom binding for input (this should be your default scenario) you have your binding models.

如果你想要一个自定义的输入绑定（这应该是你的默认场景），你有你的绑定模型。

If you have any mvc view, for admin purposes, documentation, whatever, use your ViewModels.

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

If you have a form page on mvc, you can use your BindingModel also on the POST controller. No need to have a different model for a post on MVC or WEBAPI. Specially when model binder or formatter can both understand and map to the same binding model using the same Data Annotations.

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

Sometimes, you want to create a binding model with a resource and some extra fields. Inheritance is your friend.

有时，您想创建一个带有资源和一些额外字段的绑定模型。继承是你的朋友。

Sometimes you want to create binding model with more than one resource and (optionally, extra fields) Resources as properties are your friend.

有时您想创建具有多个资源和（可选的额外字段）作为属性的资源的绑定模型。

In MVC world, you can also use the concept of 'Resource' but it is much less common. This come in handy when you have MVC and Web Api on the same project.

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

If you need further comments on any item (like folder structure, namespaces, etc), just let me know. I'm more than happy to share my cons pros experience.

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

Oh, and I forgot, a mapping strategy is worth research. I personally do my own mappings, but having this logicin one place is priceless.

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

EDIT: Very naive example

编辑：非常幼稚的例子

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;}

}

回答by Darrel Miller

If you are trying to build a REST based system then the notion of ViewModel and View can be very useful. You can fairly closely map the notion of Resource to ViewModel and representation to View.

如果您正在尝试构建基于 REST 的系统，那么 ViewModel 和 View 的概念可能非常有用。您可以将 Resource 的概念非常紧密地映射到 ViewModel，并将表示映射到 View。

If you stop to think for a moment about what a view looks like in an MVC site. It's a HTML document. A document that contains a bunch of semantic information, title, body, sections, paragraphs, tables, etc. It's not supposed to contain "style" information. That's the job of the web browser and CSS. People get confused when they start to think of HTML as UI. It's not supposed to be UI, it is the content of the UI.

如果您停下来思考一下 MVC 站点中的视图是什么样子。它是一个 HTML 文档。包含一堆语义信息、标题、正文、部分、段落、表格等的文档。它不应该包含“样式”信息。这就是 Web 浏览器和 CSS 的工作。当人们开始将 HTML 视为 UI 时，他们会感到困惑。它不应该是 UI，它是 UI 的内容。

Views are just a concrete realization of the view model content using some media type that can be transferred over the wire. What that media type is, depends on what client you are trying to satisfy.

视图只是使用一些可以通过网络传输的媒体类型的视图模型内容的具体实现。该媒体类型是什么，取决于您想要满足的客户。

回答by Julien

We are currently working on a similar project that uses ASP.Net MVC and ASP.Net Web Api.

我们目前正在开发一个使用 ASP.Net MVC 和 ASP.Net Web Api 的类似项目。

We use ASP.Net MVC to generate the global structure of our pages. Then, our MVVM javascript implementation calls the web api to fill returned data in client view models. To do that, our api returns view model that correspond to what the front end is waiting for.

我们使用 ASP.Net MVC 来生成我们页面的全局结构。然后，我们的 MVVM javascript 实现调用 web api 来填充客户端视图模型中的返回数据。为此，我们的 api 返回与前端正在等待的内容相对应的视图模型。

I think that your api view models would differ from MVC ViewModels (that are not ViewModels from a MVVM point of view).

我认为您的 api 视图模型将不同于 MVC ViewModels（从 MVVM 的角度来看，这不是 ViewModels）。

It depends on your use of api too. For example, for an internal use, you don't always need to avoid to show your domain model. So you will avoid to map the Model in the ViewModel and increase performances. But in the case you need to transform some properties in your models, viewModels will greatly help you to structure your code in a loosely coupled way.

这也取决于您对api的使用。例如，对于内部使用，您并不总是需要避免显示您的域模型。因此，您将避免在 ViewModel 中映射模型并提高性能。但是如果您需要转换模型中的某些属性，viewModels 将极大地帮助您以松散耦合的方式构建代码。

Since there are no views in webapi I guess it does not make sense to have a ViewModel as parameter.

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

I would say your api is consumed by your views in the end, it makes sense to have ViewModel.

我会说你的 api 最终被你的视图消耗了，拥有 ViewModel 是有意义的。

Does the MVC site just spit back simples views and then you use Jquery to call your webapi or do you just call MVC action methods that directly just call the same methods the Webapi would call?

MVC 站点是否只是回吐简单的视图，然后您使用 Jquery 来调用您的 webapi 还是您只是调用直接调用 Webapi 将调用的相同方法的 MVC 操作方法？

It is just a question of choice here. You can call MVC action to receive generated views (in html) or you can call WebApi to receive JSON/XML responses that you will then bind with your javascript code in your views.

这里只是一个选择问题。您可以调用 MVC 操作来接收生成的视图（在 html 中），也可以调用 WebApi 来接收 JSON/XML 响应，然后您将在视图中将其与 javascript 代码绑定。

回答by Jacob Rutherford

Just to add what others have said, the use of what would normally be termed a ViewModel is useful for validation as well. You can mark up your classes with data annotations including any validation requirements. In your controller actions you can still use ModelState to force the validation to occur and return appropriate messages via HttpRequestException or just HttpResponseMessage.

补充一下其他人所说的，使用通常被称为 ViewModel 的东西对于验证也很有用。您可以使用数据注释（包括任何验证要求）来标记您的类。在您的控制器操作中，您仍然可以使用 ModelState 强制验证发生并通过 HttpRequestException 或仅 HttpResponseMessage 返回适当的消息。