Consuming Web API and class information

Question

I currently have the following projects in a Visual Studio Solution

• MySiteAPI - Web API
• MySiteMVC - MVC 5 template

MySiteAPI is correctly serving data on http:\\\\localhost\\api and I want to consume that in MySiteMVC .

MySiteAPI currently has Entity Framework Code First classes to handle the data side

I'm confused on how to pull the data into the class definitions on MySiteMVC since the definitions are in MySiteAPI project and not in MySiteMVC . It also appears that Web API can't be called as a Web Reference to get class information, which is where I'm stuck.

I believe this is an architectural problem and want to make sure I understand the proper way to do this before I restructure this project.

I don't want to reference MySiteAPI into MySiteMVC because that sort of defeats separating the two projects. I'm trying to be more robust about this.

Instead of placing the class definitions inside of MySiteAPI project, should a class library be created that handles the entity framework for the data which both projects reference?

If so, would the class library contain only the class definitions and MySiteAPI project would be the project that does the database operations via a DbContext ? This seems to be what makes most sense to me.

In this case there would be three projects

• MySiteModels - Holds class definitions
• MySiteAPI
• MySiteMVC

Both MySiteAPI and MySiteMVC would reference MySiteModels

Is this a correct way to do this? Is there a more appropriate way?

Answer 1

Yes, your problem seems to be architectural. There are many different approaches to achieve better architecture for your problem (it also depends on the size of your project) but I will describe the one I think is the most suitable, flexible, testable for medium projects.

The models are defined in separated class library project for example MyProject.Models . In this project there are only POCO which doesn't know anything about WebApi, Mvc or entity framework projects. They should be completely decoupled and possible to use from any other projects.

The 'entity framework project' or 'data' is defined also in separated class library project for example MyProject.Data . This project references only entity framework and the Models project. Here is defined the derived DbContext class. The project is responsible for connection and operating over the database. If you use some patterns like Respoistory or Unit Of Work patterns (which I think is much better than initializing DbContext everywhere where you need it) they can be placed in this project too.

The WebApi and Mvc are two separated 'client' projects. Both reference Models project, the WebApi references the Data project and Entity Framework too. But both client projects don't know anything each other. You can give them their thin (dll) dependencies and host them on different servers if you want. If the MVC project will have individual users authentication using the identity it should reference other similar structure of projects (data, models, entity framework, separated DbContext) or use the already defined one.

If you plan to test your code (I recommend it) there will be one (or more) test projects called for example MyProject.Tests . The tests projects reference Models , Data (or fake implementation of Data ) and WebApi or Mvc project depends on what is testing.

For DbContext, Repository, Unit of Work and some other classes there should be few interfaces which can be placed in different class library for common interfaces.

Let's summarize:

1. MyProject.Models - The POCO data models. No other references.
2. MyProject.Data - The DbContext, Repository, Unit of Work. Reference to Models and Entity Framework.
3. MyProject.WebApi - The WebApi project. References - Models, Data, Entity Framework.
4. MyProject.MVC - The MVC project. References - Models (optional Data and Entity Framework).
5. MyProject.Test - The test project. References - Models, Data (or Fake Data), the projects fro testing.