I'm using ASP.NET MVC and ASP.NET Web API in the same project. I'm debating whether to keep the models for these separate (i.e., putting MVC models in a "Models" folder and putting Web API models in an "ApiModels" folder).
Should I (not) do this? Could separating them cause problems? Will keeping them together and using the same models for both MVC and Web API cause problems?
Should I (not) do this?
I have to agree with both codehunter and HollyStyles. It depends, but you should tend to lean towards "keep them separate".
Could separating them cause problems?
Not necessarily, but it depends on your definition of problems. If you have a naive or inexperienced developer working on the code, they could look at it and say "Hey, your code is not DRY, you suck." They could be wrong of course, but you still have to explain why to them, so that could be a problem.
Will keeping them together and using the same models for both MVC and Web API cause problems?
No, and let me give a reason why. Models for MVC and WebAPI are consumed by different frameworks. For example, in order to make sure a model property renders as a hidden input, you might decorate it with the [HiddenInput] attribute. There is no such concept in WebAPI models. Similarly, MVC has Display, Remote, and other attributes that you usually won't use on WebAPI models.
On the other side of the same coin, WebAPI models can use [DataContract] and [DataMember] attributes that don't have any meaning in MVC. You use these to give special names to your API output (for example, renaming XML or JSON nodes).
While you could have a single model double for use in both MVC and WebAPI, you could end up with those models having mixed concerns: for example, a [DataMember] attribute for API output formatting, and a [HiddenField] attribute for MVC form view rendering. One could view this as a manifestation of pollution.
As long as your model classes are simple data containers with no methods or intelligent behaviors, it's not a violation of DRY to have different model classes with the same properties / schemas. Why? Because it allows you to decorate these classes with different attributes that address different concerns.
Then again, if your models don't use any of these attributes, and you don't plan to, then it would be okay to have the same models double for both MVC and WebAPI. So the answer really is, it depends.
As usual the answer to this type of question is: "Hmmm, It depends"
Personally I have a class library just for poco models that both the data layer, my restful layer and web application all reference.
The only gotcha I found before doing this was that LinqToSql generated classes (and therefore probably EF too) can have circular references, which WebApi chokes on when serializing to JSON in the ApiController class, it ends up in a infinite loop.
I say NO at first sight, since both have it's own purpose.
viewmodel in mvc are meant for properties that represents views and validation for data it processsed. where as web api doesn't seems used for this purpose. therefore we always have properties even we have entities which can be serve as viewmodel.
Also, it will make application harder to manage on changes.
BUT, you can USE it if your have application considerably smaller.
I would say if you are going to have to just recode or copy and past everything if you separate them, then don't separate them. If separating them means no copying anything then you are safe and smart to separate.
