Соглашения о наличии как API, так и проекта MVC в решении .NET Core

Question

У меня есть приложение ASP.NET Core (.NET Core 2.2) со следующими проектами:

• API: предназначен для представления WebAPI (с наследованием контроллеров ControllerBase)
• Службы: содержит службы, которые контроллеры API используют для доступа к базе данных и т. Д.
• База данных: содержит обычные репозитории БД, которые сервисный уровень использует для доступа к базе данных

Теперь я хочу добавить пользовательский интерфейс, который взаимодействует с API (часть pre-.NET-core MVC). Как это достигается с помощью .NET Core, где MVC и WebAPI - это одно и то же? Должны ли контроллеры / модели / представления MVC быть частью API? Должен ли он быть новым проектом, который прослушивает другой порт? Как аутентификация подходит для обоих (например, API обычно имеют некоторую аутентификацию на основе токенов, приложения UI обычно имеют аутентификацию по имени пользователя / паролю)? Должны ли части WebAPI и MVC использовать одну и ту же аутентификацию, что и удостоверение ASP.NET? Разве это не будет тесно связано между собой, если они будут использовать одну и ту же базу данных?

Существует ли какое-либо соглашение от Microsoft или сообщества о том, как структурировать такие проекты?

Answer 1

Я думаю, что вы немного запутались в WebAPI по сравнению с MVC.

Вы можете видеть WebAPI как простые веб-службы, отвечающие на http-запрос с данными (какими бы ни были данные, они могут даже включать javascript или ресурсы).

РЕДАКТИРОВАТЬ: Таким образом, отправка информации "UI", безусловно, является частью вашего API и проекта службы.

В API вам потребуется создать выделенные контроллеры для отправки ваших частей «пользовательского интерфейса».На Сервисе вам нужно будет создать специальные сервисы для получения информации о «пользовательском интерфейсе» (есть много способов сделать это, используя Ressources, получать данные в облаке и т. Д.)

EDIT2: Но ничто не мешает вамот создания совершенно другого решения для частей пользовательского интерфейса.Если вы снова выбрали WebAPI, вам все равно нужно будет применить ранее упомянутую логику API / Service.Вам решать выбрать то, что вам удобно.

Answer 2

API можно добавить только в том случае, если он вам действительно нужен.

Планируете ли вы выставить что-нибудь другому приложению?

Если вам нужен только пользовательский интерфейс, взаимодействующий с базой данных, не беспокойтесь, используйте службы для извлечения данных, вызова их из контроллеров MVC и полного пропуска части API.

Вам не нужен API для такого ограниченного случая использования.API вводит множество других вещей, которые необходимо учитывать, таких как аутентификация и безопасность.Не усложняйте вещи, когда вам это не нужно.

Answer 3

Ответ на ваш вопрос в основном «зависит от ваших вкусов», но, на мой взгляд ...

Если вы не планируете выставлять API другим приложениям, оставляйте контроллеры API такими же.приложение, которое размещает контроллеры MVC (или Razor Page).Когда у меня есть контроллеры MVC и контроллеры API, я помещаю их в отдельные папки.Я думаю, что это нормально, потому что ваши контроллеры должны быть очень тонкими.Я обычно помещаю всю бизнес-логику (включая любой необходимый доступ к данным) в сервисы, которые встроены в отдельную библиотеку классов.

Answer 4

Как это достигается с .NET Core, где MVC и WebAPI - это одно и то же?

В ядре dotnet MVC и WebAPI могут присутствовать в одном проекте.Все приложение похоже на консольное приложение.Вы можете добавить службы MVC в класс запуска, чтобы сделать его приложением MVC.

Должны ли контроллеры / модели / представления MVC быть частью API?

Лучше иметьразличные контроллеры для функций, связанных с MVC и WebAPI, отдельно, сохраняя их в одной папке.

Модели - их можно использовать как для mvc, так и для webapi.То же самое для моделей представлений и DTO.

Представления - только для MVC webapi не требует представлений.

Должно ли это быть новый проект, который прослушивает другой порт?

Да, вы можете создать другой проект для webapi и MVC.

Как аутентификация подходит для обоих (например, API обычно имеют некоторую аутентификацию на основе токена, приложения пользовательского интерфейса обычноесть аутентификация по имени / паролю)?

Если вы используете аутентификацию на основе токенов, то сможете использовать как веб-API, так и MVC.

Если части WebAPI и MVCиспользовать ту же аутентификацию, что и ASP.NET Identity?Не будет ли это тесно связывать два, если они используют одну и ту же базу данных?

Если вы используете ASP.Net Identity с сервером идентификации, то и MVC, и webapi смогут совместно использовать один и тот же механизм аутентификации безмуфта.