Создание веб-приложений

Архитектура внешнего интерфейса с веб-приложением Blazor

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

lino web-app new --name <WebAppName>

Эту команду необходимо запустить в проекте Lino. Он запрашивает имя веб-приложения, использует шаблон веб-приложения Blazor, подтверждает выбранные данные, создает необходимые файлы и выполняет команды, подключающие интерфейс к решению. Каноническая форма web-app. Псевдонимы webapp и web существуют для повышения производительности, но предпочтение должно отдаваться документации и примерам lino web-app new чтобы сохранить последовательность.

Что генерируется

Веб-приложение Blazor, созданное Lino, — это не просто папка с экранами. Он вписывается в то же решение .NET и следует модульной организации, используемой серверной частью, разделяя обязанности между хостом, клиентом, общими компонентами и проектами пользовательского интерфейса для каждой службы или модуля.

• Серверный проект: размещает веб-приложение Blazor, сопоставляет корневые компоненты, настраивает параметры службы по умолчанию, статические ресурсы, защиту от подделки, службы HTTPS, MudBlazor и режимы интерактивного рендеринга.
• Клиентский проект: Сосредоточивает компоненты, работающие на стороне WebAssembly, маршрутизацию, макет, структуру меню, настройки браузера, возможности локализации и интеграцию с MudBlazor.
• Общий проект веб-приложений: централизует общие ресурсы пользовательского интерфейса, уведомления, диалоговые окна, шаблоны строк запросов, результаты клиентов, службы культуры/часового пояса и повторно используемые компоненты.
• Дизайн пользовательского интерфейса по сервисам и модулям: Если в решении есть службы и модули, Lino создает проекты внешнего интерфейса в рамках платформы веб-приложений для поддержки контекстно-изолированных страниц, меню и ресурсов.

Сгенерированные регистры хоста AddInteractiveServerComponents и AddInteractiveWebAssemblyComponents. Корневые компоненты HeadOutlet и Routes использовать InteractiveAuto, что позволяет приложению запускаться в интерактивном режиме через сервер и переходить на WebAssembly, когда доступна среда выполнения клиента.

Интеграция с бэкендом APIs

Если веб-приложение существует, Lino сохраняет серверную часть подготовленной для типизированного использования внешним интерфейсом. Сервисы и модули могут получать проекты Api.Contracts и Api.Client, предоставляя контракты запроса/ответа и типизированные клиенты сгенерированным конечным точкам.

• Пользовательскому интерфейсу не требуется вручную собирать необработанные вызовы HTTP для каждой функции.
• Сгенерированные страницы вызывают клиентов типа API и работают с моделями запросов и ответов, созданными вместе с бэкэндом.
• Модели опубликованы как ClientResult, QueryParams и PagedQueryParams стандартизировать обработку результатов, фильтры, нумерацию страниц и визуальную обратную связь.
• Интеграция через типизированный HttpClient поддерживает соответствие frontend контрактам, разрешениям, сообщениям проверки и культурам, используемым остальной частью решения.

Практический ход таков:

Страница Blazor -> типизированный API-клиент -> endpoint Minimal API -> Command/Query -> база данных

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

Включенные функции пользовательского интерфейса

Сгенерированное веб-приложение уже подготовлено к общим задачам реальных приложений:

• Маршрутизация компонентов Routes.razor генерируется.
• Верстка, навигация и визуальные компоненты на основе MudBlazor.
• Генерация меню со страниц, доступных в каждом сервисе или модуле.
• Файлы .resx для поиска текстов в культурах, настроенных в проекте.
• Поддержка аутентификации, хранения токенов, защищенных маршрутов и служб разрешений, когда функция аутентификации включена.
• Меню, чувствительные к авторизации, отображающие записи только в том случае, если у текущего пользователя есть необходимое разрешение.

Несколько интерфейсов

Один бэкэнд может поддерживать более одного веб-приложения. Это полезно, когда разным аудиториям нужны разные навигация, безопасность, опыт и развертывание, но они должны продолжать использовать одни и те же службы, модули, варианты использования и API.

• Публичный сайт: страницы, доступные клиентам, посетителям или пользователям, которые еще не прошли аутентификацию.
• Бэк-офис/Администратор: внутренняя панель управления для операторов, групп поддержки и администраторов.
• Партнерский портал: Ограниченный доступ для партнеров, реселлеров, поставщиков или операционных интеграторов.
• Зона самообслуживания: опыт, ориентированный на конечных клиентов, со своими меню и разрешениями.

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

Создание веб-страниц

После моделирования сущности, определения вариантов использования и генерации команд, запросов, конечных точек и постоянства следующим шагом обычно является раскрытие функциональности интерфейса. Lino автоматизирует этот шаг с помощью генератора страниц:

lino page new --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>
lino page edit --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>
lino page list --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>

Варианты также могут быть сообщены в интерактивном режиме. Команда запрашивает службу, модуль, сущность, целевое веб-приложение, тип страницы и свойства, которые должны появиться в сетке. Наиболее распространенным типом является CRUD; когда объект поддерживает только запрос, Lino может создать страницу типа DataGrid.

нспользовать page new создать первую версию экрана, page edit когда странице необходимо отслеживать изменения в полях, контрактах или поведении, и page list чтобы понять, что уже было создано для сущности.

Рекомендуемый расход

1. Создайте или выберите веб-приложение с помощью lino web-app new.
2. Моделируйте объект и создавайте варианты использования, запросы, команды, конечные точки, контракты API и артефакты персистентности.
3. Бегать lino page new и выберите объект, который получит интерфейс.
4. Внимательно выбирайте поля в сетке. Они становятся видимыми столбцами и помогают настроить параметры запроса, фильтры и нумерацию страниц.
5. Запустите решение через AppHost, чтобы вместе проверить пользовательский интерфейс, API, аутентификацию, разрешения и интеграцию базы данных.

Сгенерированная структура

Для страницы CRUD Lino создает полный пакет страницы Blazor вместо одного файла Razor:

• Запись страницы или индекса, координирующего листинг, создание, редактирование, детализацию и удаление.
• Компонент Grid на основе MudBlazor с загрузкой на стороне сервера, нумерацией страниц, фильтрами и сопоставлением параметров запроса.
• Компонент формы с типизированной ViewModel и расширениями для сопоставления запросов на создание, обновление и получение идентификатора.
• Ресурсы для заголовков, меток, кнопок, сообщений проверки и локализованных текстов интерфейса.
• Проверка разрешений при включенной аутентификации, включая проверку доступа к странице и условные кнопки.

Создание страницы CRUD для сущности Vehicle, например, в сервисе Fleet, модуль Operations и веб-приложение Backoffice, структура имеет следующий формат:

src/WebApps/Backoffice/Services/Fleet/Operations/Pages/Vehicles/Registration/
├── Vehicle.razor
├── Vehicle.razor.cs
├── Resources/
│   ├── VehicleResources.resx
│   └── VehicleResources.Designer.cs
└── Components/
    ├── Form/
    │   ├── VehicleForm.razor
    │   ├── VehicleForm.razor.cs
    │   ├── VehicleFormExtensions.cs
    │   ├── VehicleViewModel.cs
    │   └── Resources/
    │       ├── VehicleFormResources.resx
    │       └── VehicleFormResources.Designer.cs
    └── Grid/
        ├── VehicleGrid.razor
        ├── VehicleGrid.razor.cs
        ├── VehicleGridExtensions.cs
        ├── VehiclePagedQueryParams.cs
        └── Resources/
            ├── VehicleGridResources.resx
            └── VehicleGridResources.Designer.cs

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

Как работает сгенерированная страница

На странице используются те же контракты, сгенерированные для API. Сетка преобразует фильтры и нумерацию страниц в запрос листинга; форма преобразует ViewModel в запросы на создание или обновление; типизированный клиент API отправляет вызов соответствующей конечной точке. Конечная точка выполняет сгенерированную команду или запрос и возвращает типизированный ответ в пользовательский интерфейс.

Frontend -> API -> Commands/Queries -> база данных

При наличии авторизации сгенерированный код также проверяет разрешения, такие как перечисление, создание, редактирование, удаление и запрос по идентификатору. Это влияет как на доступ к странице, так и на видимость действий для пользователя.

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

Многоязычный интерфейс

Веб-приложения, созданные Lino, используют файлы. .resx для локализованных текстов. Это позволяет вам поддерживать одну и ту же структуру Razor и изменять заголовки, метки, кнопки, сообщения об ошибках, тексты проверки и описания в зависимости от активной культуры.

Локализацию не следует рассматривать как визуальную отделку. На административных страницах и операционных порталах противоречивые термины вызывают сомнения в отношении бизнес-правил. Таким образом, ресурсы являются частью архитектуры пользовательского интерфейса и должны сопровождать страницы, формы, сетки и общие компоненты.

• Держите клавиши стабильными, описательными и ориентированными на смысл, избегая названий, привязанных к временному макету экрана.
• Избегайте жестко запрограммированного текста на страницах и компонентах; используйте ресурсы для меток, сообщений, заголовков, хлебных крошек, меню и подтверждений.
• Просмотрите технические условия, чтобы обеспечить согласованность документации, контрактов CLI, API и интерфейса.
• Сохраняйте один и тот же набор ключей для разных языков, чтобы предотвратить неожиданный возврат или частично переведенные экраны.
• Отдельный дословный перевод от адаптации продукта: когда термин необходимо локализовать для конечного пользователя, сохранить функциональный смысл действия.

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

Отзывчивый, готовый к использованию CRUD

Сгенерированный CRUD ускоряет доставку, поскольку создает повторяющуюся основу экрана: список, форму, интеграцию с API, ресурсы, нумерацию страниц, фильтры, действия и код программной части. Тем не менее, его следует рассматривать как опыт использования продукта, а не просто техническую основу.

Хороший экран CRUD должен позволять пользователю находить записи, понимать текущее состояние, уверенно предпринимать действия и восстанавливаться после сбоев. Это касается как внутренних экранов бэк-офиса, так и порталов, ориентированных на клиентов или партнеров.

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

Отправную точку, созданную Lino, следует рассматривать как последовательную и интегрированную основу. После этого команда настраивает визуальную плотность, порядок полей, правила отображения, разрешения и тексты, чтобы они отражали фактический процесс разработки продукта.