Does it Make Sense to have ViewModels in the Webapi?

Question

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.

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

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

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.

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

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?

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.

Answer 1

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

BindingModels for data binding (mvc or api)

ViewModels for 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.

ResourceModel for 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.

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.

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.

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.

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

Answer 2

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.

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.