#c# #docker #asp.net-core #blazor
#c# #docker #asp.net-ядро #blazor
Вопрос:
В настоящее время мы планируем нашу архитектуру создания ASP.NET Веб-сайт, основанный на ядре. У нас разные ASP.NET Основные приложения (микросервисы), которые выполняют разные задания. Давайте рассмотрим два из них в качестве примера для этого случая. Один из них обрабатывает базу данных, которую мы используем (добавляет, удаляет или редактирует что-то, например), а другой сервис собирает результаты другого интерфейса.
Теперь у нас появилась идея использовать Blazor в качестве фреймворка для отображения всего. Но в некотором смысле у каждой службы есть свой собственный «веб-сайт» только с одной страницей, где все, что нужно сделать каждой службе, можно сделать или можно увидеть.
Я думаю, это должно быть возможно. Теперь часть, в которой я не уверен: должен быть третий ASP.NET Основной проект, который имеет что-то вроде главного меню для перенаправления на «веб-сайты» микросервиса. Возможно ли это? Если да, рекомендуется ли делать это таким образом или лучше иметь все страницы в проекте main menu и собирать данные из микросервисов с помощью http-запросов и отображать их?
Чтобы сделать это быстро, это были бы проекты, которые у нас были бы:
- Тот, который собирает данные из базы данных, имеющей одну страницу в стиле Razor
- Тот, который собирает данные из другого интерфейса, имеющего одну страницу в стиле Razor
- Тот, у которого есть главное меню для перенаправления на страницы в стиле Razor двух других проектов
РЕДАКТИРОВАТЬ Я забыл сказать, что я хотел бы иметь меню с правой стороны на любом сайте, который я посещаю. Например, если я попытаюсь сравнить его с WPF, у вас есть главное представление с меню, но вы показываете другие представления во фрейме. /РЕДАКТИРОВАТЬ
Я впервые работаю с ASP.NET Ядро или с веб-сервисами. Если что-то, что я сказал, не имеет для вас смысла, извините. Дайте мне знать, и я постараюсь объяснить это понятным способом.
Комментарии:
1. Вместо Blazor подумайте о React # — объектная модель Blazor очень похожа на React. Он содержит компоненты , которые могут поступать из других проектов или вызывать разные службы. Кстати, как и любой другой SPA. Это означает, что вы должны понимать, как работают SPAS и React. Попытка использовать WPF в качестве модели — плохая идея
2. Приложение Blazor, как и React, представляет собой иерархию компонентов от корневого каталога до отдельных элементов HTML. Таким образом, нет
all pages in the main menu— на самом деле меню — это еще один компонент, отображающий либо статические данные, либо данные, полученные из сервиса, либо данные, переданные от его родителя3. Спасибо за ваш ответ @PanagiotisKanavos. Я понимаю вашу точку зрения по страницам, но, честно говоря, я все еще не уверен, что делает React # в сравнении лучше, чем Blazor, по вашему мнению. Не могли бы вы объяснить это немного подробнее, пожалуйста?
4. Это не то, что я сказал. Я сказал, что Blazor — это React # . Он использует ту же компонентную модель, тот же способ распространения состояния только сверху вниз. Это совсем не похоже на WPF. Blazor использует компоненты от корня вплоть до HTML. Он делает это так же, как и React. Даже маршрутизатор, который направляет действия на определенные «страницы» (фактически компоненты), является компонентом, расположенным прямо под компонентом приложения
5. Перечитав ваш ответ, я понял. Извините. Спасибо! Теперь мне любопытно, почему мой вопрос был отклонен. Есть ли что-нибудь, что я могу сделать лучше в следующий раз?
Ответ №1:
Я бы сделал именно то, что вы предлагаете, чтобы иметь главное меню, которое переходит к двум другим проектам, но я думаю, что это также зависит от ваших точных требований, если это необходимо. Другой вариант, который у вас есть, — создавать только внутренние микросервисы и сохранять все интерфейсные приложения в одном приложении. Я думаю, это действительно зависит от того, насколько далеко вы хотите продвинуться по «микросервисной» архитектуре, и перевешивают ли преимущества время, необходимое для поддержки проектов. Ссылка ниже, которая помогает объяснить разные мысли о том, какая идея может быть лучше.
Дайте мне знать, что вы думаете!
Комментарии:
1. Это звучит очень интересно. Я не думал о поиске микро-интерфейсов. Я уверен, что это поможет. Спасибо!
2. После разговора с моими коллегами мы решили попробовать пойти по пути, который вы предложили, используя микро-интерфейсы. Еще раз спасибо!
3. @theoneandonlyprogrammer нет проблем, рад помочь!