Какой шаблон проекта выбрать, если я хочу отдельный веб-API, но все же запустить на стороне сервера, а затем на стороне клиента?

Question

При создании проекта ASP.NET Core с использованием Blazor это представляет некоторые интересные архитектурные решения. Есть 3 разных шаблона проекта.
- Blazor
- Blazor (размещено на ASP.NET Core)
- Blazor (на стороне сервера в ASP.NET Core)

Вопрос 1
Я пытаюсь понять цель или преимущество шаблона Blazor (на стороне сервера в ASP.NET Core) или подхода к структурированию проекта. Почему основное приложение .NET обслуживает другое основное ядро ​​.NET? Или я что-то упустил? Учитывая различные модели хостинга, объясненные здесь.
https://blazor.net/docs/host-and-deploy/hosting-models.html
Разве это не может быть просто один проект, который использует серверный Blazor, а не 2?

Вопрос 2
Если я смотрю на архитектуру, подобную той, что показана на изображении ниже, не должен ли я начать с шаблона «ASP.NET Core Hosted», а затем изменить проект .Client для использования инфраструктуры «на стороне сервера»? Таким образом, у меня все еще есть вызываемый API, к которому можно получить доступ из другого приложения, если это необходимо? Или я полагаю, что я все еще могу использовать шаблон «Серверная сторона», который предварительно настроит все параметры запуска для запуска Клиента с помощью серверной модели хостинга, и объединит это с добавлением моих собственных контроллеров API в .Server. проект, который будет вызываться через библиотеку бизнес-правил согласно схеме.

Вопрос 3
В какой-то момент я мог бы захотеть переключить приложение .Client на использование веб-сборки, когда улучшится поддержка инструментов / отладки. Я не думаю, что архитектура, которую я предлагаю, запрещает это? Я просто изменил бы код запуска в приложении .Server, заменил ссылку на blazor.server.js на blazor.webassembly.js и несколько других вещей, и я должен быть золотым. Я с базы здесь?

Замечания по архитектуре:
- Клиентскому приложению необходим доступ к ресурсу с помощью некоторой операции CRUD, поэтому он выполняет вызов метода в библиотеке классов бизнес-правил
- Библиотека бизнес-правил ссылается на библиотеку классов, которая содержит «тупые» классы POCO, которые представляют различные доменные модели. Делает вызов в API
- Контроллер / действие API затем вызывает библиотеку данных или репозиторий, который управляет Entity Framework DbContext для извлечения / обновления данных в Db
- И библиотека бизнес-правил, и библиотека данных, и API-интерфейс ссылаются на библиотеку «Модели».

Answer 1

Может быть, это Шаблон Blazor может помочь вам достичь того, что вы хотите

Я хочу отдельный веб-API, но все же работать на стороне сервера, а затем на стороне клиента?

Шаблоны Blazor (Автор здесь)

Это шаблон проекта Visual Studio 2019 Preview 3 для создания Blazor v0.8.0 решения, которые могут быть размещены на стороне клиента или сервера, Идея заключается в том, чтобы иметь удобную реализацию, которая позволяет легко переключаться между моделями хостинга.

Так что в основном в том же решении у вас будет:

• web-api (ASP.Net Core Hosted)
• на стороне сервера (компоненты Razor с SignalR и отладкой)
• на стороне клиента (SPA + веб-сборка)

Таким образом, во время разработки вы можете выбрать и запустить проект на стороне сервера, чтобы иметь полные возможности отладки C #, затем выбрать проект на стороне клиента и опубликовать его в качестве автономного SPA, работающего через веб-интерфейс без касания. одна строка кода.

Более того, при работе в режиме на стороне сервера можно использовать не только компоненты Razor с SignalR и отладкой, но и контроллеры Web API, чтобы вы могли смоделировать фактическое поведение, которое будет иметь приложение в работе.

Надеюсь, это поможет

Answer 2

Вопрос 1: Рендеринг на стороне сервера имеет ряд преимуществ, включая:

1. Поскольку обновление пользовательского интерфейса выполняется через соединение SignalR, мы можем избегайте ненужных обновлений страниц.
2. Размер загружаемого приложения меньше, а начальное приложение загружается быстрее. Компонент Blazor может в полной мере использовать возможности сервера такие как использование .NET Core совместимых API.
3. Он также будет поддерживать существующие инструменты .NET, такие как отладка компиляция приложений и JIT.
4. Поскольку серверная часть Blazor работает под собственным процессом .NET Core, и не под Mono WebAssembly, он также поддерживается в браузерах, которые не имеют поддержки WebAssembly.

Да, у вас может быть одно приложение на стороне сервера с доступом к БД без использования API. Это, в свою очередь, ограничит ваше приложение рендерингом на стороне сервера, если вы не выполните рефакторинг.

Вопрос 2: Да, я считаю, что у вас все будет хорошо, если вы пишете свой код для поддержки функциональности клиента. например, Http-запросы от приложения к API.

Вопрос 3: Да, вы правы, сделав несколько небольших изменений в коде, которые вы сможете поддерживать как на стороне сервера, так и на стороне клиента. Я хотел бы спросить, как вы пишете свой код на клиенте, т. Е. Если бы вы использовали стандартные библиотеки .net, они могут не полностью поддерживаться клиентом. Кроме того, если вы сначала создали приложение на стороне сервера и сделали сервисы для вызова, чтобы получить данные, например, обращаясь к контексту базы данных, при переключении на конфигурацию веб-клиента вам, скорее всего, потребуется выполнить http веб-запросы.

Дополнительную информацию о переключении опыта можно найти здесь: Ссылка