ASP.NET - Single Solution, MVC and WebApi projects, Separate Models for Each?

Question

We've got a solution with multiple MVC web projects and now adding a client-facing WebApi project.

The API will be a much more scaled-down version of what is available through any of the web projects (though it will likely expand much more over time), so we've come to a decision-making point for how to handle the Models.

What are the best practices for handling Models across different projects?

It's my understanding that a Model in a WebApi project will, for example, use certain property attributes which are meaningless to an MVC web application. And also as an example, the Display attribute is meaningless to the WebApi, but very useful in a View.

This leads me to believe I should be creating a separate set of Models for the WebApi, but also wondering if I'm missing something.

I understand that this could be a question that may lead to a range of opinions, so I'm mostly looking for what are considered industry best practices.

Answer 1

In my solution where i have Web API and MVC web app, I have the below structure

Models : My Entity/Business objects. These are created by Entity framework from my database. These are almost same as my db structure. My Repositary methods (for data access) returns either a single instance /collection of instances of this classes. My data access project is a separate class library which has been referred in other places like my web api project etc..

Web API ViewModels : The Viewmodels (POCO class) specific to the Web API interfaces/action methods.

MVC Web app ViewModels : The Viewmodels (POCO class) specific to my razor views. I had even inherited few of these from the Web API Viewmodels and added additional properties as needed.

Answer 2

I use a separate project for the DTOs, so that the projects that need to consume them do not get into issues with circular references.

I would have the WebApi project map your models into the DTOs. If your MVC project is consuming the WebAPI output, it just needs a reference to the DTO project. This keeps you from having to refer to the WebAPI project directly.