.NET Core解决方案中同时具有API和MVC项目的约定

Question

I have an ASP.NET Core (.NET Core 2.2) app structured with the following projects:

• API: this is meant to represent a WebAPI (with controllers inheriting ControllerBase )
• Services: This contains services which the API controllers utilize to access the database, etc
• Database: This contains the usual DB repositories, which the services layer utilize to access the database

Now, I want to add a UI that talks to the API (the MVC part pre-.NET-core). How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing? Should MVC controllers/models/views be part of the API? Should it instead be a new project that listens on a different port? How does authentication fit in for both (eg APIs usually have some token-based authentication, UI apps usually have username/password authentication)? Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?

Is there some kind of Microsoft or community suggested convention/documentation for how to structure such projects?

Answer 1

I think that you are a bit confused about WebAPI compared to MVC.

You can see WebAPI as simple web services answering http request with data (whatever the data is, it could even include javascript or assets).

EDIT: So sending "UI" informations is definetly a part of your API and Service project.

On API you will need to create dedicated controller(s) to send back your "UI" part(s). On Service you will need to create dedicated service(s) to fetch the "UI" informations (their is many way to do this, using Ressources, fetching data on Cloud, etc)

EDIT2: But nothing prevent you from creating an entirely different solution for UI parts. If you chose WebAPI again, you will still need to enforce the previously mentioned API/Service logic. It's up to you to chose whatever you feel confortable with.

Answer 2

How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing?

In dotnet core MVC and WebAPI can be present in the same project. Everything application is like a console application. You can add MVC services to startup class to make it an MVC application.

Should MVC controllers/models/views be part of the API?

Its better to have different controllers for MVC and WebAPI related functions separately while keeping them in the same folder.

Models - They can be reused for both mvc and webapi. Same for view models and DTOs.

Views - Just for MVC, webapi does not require views.

Should it instead be a new project that listens on a different port?

Yes, you can create a different project for webapi and MVC.

How does authentication fit in for both (eg APIs usually have some token-based authentication, UI apps usually have username/password authentication)?

If you use token-based authentication then both web API and MVC will be able to use.

Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?

If you use ASP.Net Identity with identity server then both MVC and webapi will be able to share the same authentication mechanism without tightly coupling.

Answer 3

The answer to your question is mostly, "it depends on your tastes" but in my opinion...

Unless you are planning on exposing the API to other applications, keep the API controllers in the same application that hosts the MVC controllers (or Razor Page). When I have both MVC controllers and API controllers I put them under separate folders. I think this is OK, because your controllers should be very thin. I generally put all the business logic (including any necessary data access) in services that are built in a separate class library.

Answer 4

You only add an API if you actually need it.

Do you plan to expose anything to another app?

If all you want is a UI which interacts with a database then don't bother, use the services to retrieve the data, called them from the MVC controllers and skip the API part completely.

You don't need an API for such a limited use case. An API introduces a host of other things to consider, like authentication and security. Don't complicate things when you don't need to.