在Webapi中使ViewModel有意义吗?

我开始学习webapi,并发现自己在MVC项目中有意义,但可能没有意义。

通常在MVC项目中,我制作ViewModels并将其用作参数,或者将其传回给视图。

由于在webapi没有意见,我想这是没有意义的有一个ViewModel作为参数。

我想知道如果我应该只是作为一个参数我EF域(代码第一),并把数据注释在这些之上。 我通常会把注释放在视图模型属性上,因为我喜欢这个域名。

但是,阻止我这样做的是我不是100%清楚我的MVC网站将如何工作。

MVC网站是否吐出简单的视图,然后你使用Jquery来调用你的webapi,或者你只是调用MVC的动作方法,直接调用Webapi将调用相同的方法?

如果是第二种方法,那么我宁愿把数据注释放在我的视图模型上,但是我在EF域和虚拟机上放了相同的数据,看起来多余。

撇开术语,有模式绑定仍然有用。 他们在技术上不再是ViewModel,因为你没有任何意见。 但他们肯定还是有用的。 使用它们可以让您充分利用模型属性的属性,并允许您在需要时通过API重用它们。 另外请记住,如果您直接使用您的实体,WebAPI将模型将所有参数绑定到与名称匹配的参数,即使您不打算这样做。

此外,实体模型是原始数据的表示forms,但用于绑定的模型是API请求需要满足以成功处理请求的固定合同。 在完成实现的时候,这些值可能会跨越多个实体模型,而不是永远不会被持久化到数据存储。

我在这个“事情”上花费时间后的build议是:

用于数据绑定的绑定模型(mvc或api)

ViewModels在mvc上的视图(你可能在你的api中有一些mvc页面,所以最好有一个地方,这可以是文档,介绍页面,如果没有视图,那么你可以有零视图模型)这样做的好处是你可以在你的Views / web.config中有ViewModels命名空间的参考,它不会被你的api资源所污染。

用于web api资源的ResourceModel 。 在webapi中,嵌套的资源也是资源,它们在mvc中不常见的树中的任何位置,因此为它们命名资源非常有意义。

如果你想接收资源,你可以使用你的资源模型。 记住你正在收到你正在发回的信息。

如果你想要一个自定义绑定的input(这应该是你的默认场景),你有你的绑定模型。

如果你有任何mvc视图,为了pipe理目的,文档,无论如何,使用你的ViewModels。

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

有时候,你想创build一个具有资源和一些额外字段的绑定模型。 inheritance是你的朋友。

有时你想创build具有多个资源的绑定模型,并且(可选地,额外的字段)资源作为属性是你的朋友。

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

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

如果你停下来想一下MVC网站的视图是什么样子的。 这是一个HTML文档。 包含一系列语义信息,标题,正文,部分,段落,表格等的文档。不应包含“样式”信息。 这是networking浏览器和CSS的工作。 当人们开始将HTML视为UI时,人们会感到困惑。 它不应该是UI,而是UI的内容。

视图只是使用一些可以通过networking传输的媒体types的视图模型内容的具体实现。 媒体types是什么,取决于你试图满足的客户端。

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

我们使用ASP.Net MVC来生成我们页面的全局结构。 然后,我们的MVVM JavaScript实现调用Web API来填充客户端视图模型中返回的数据。 要做到这一点,我们的api返回与前端等待的内容相对应的视图模型。

我认为你的api视图模型会不同于MVC ViewModels(从MVVM的观点来看不是ViewModel)。

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

由于在webapi没有意见,我想这是没有意义的有一个ViewModel作为参数。

我会说你的api最终被你的视图所占用,所以有ViewModel是有道理的。

MVC网站是否吐出简单的视图,然后你使用Jquery来调用你的webapi,或者你只是调用MVC的动作方法,直接调用Webapi将调用相同的方法?

这只是一个select的问题。 您可以调用MVC操作来接收生成的视图(以html的forms),或者您可以调用WebApi来接收JSON / XML响应,然后将您的视图中的JavaScript代码绑定到JSON / XML响应。

为了增加别人的话,使用通常被称为ViewModel的东西对于validation也是很有用的。 您可以使用数据注释标记您的课程,包括任何validation要求。 在您的控制器操作中,仍然可以使用ModelState强制进行validation,并通过HttpRequestException或HttpResponseMessage返回适当的消息。