Web アプリケーションの作成

Blazor Web アプリを使用したフロントエンド アーキテクチャ

Lino によって生成された Web アプリケーションは、API ツールへの呼び出しだけでなく、実際のインターフェイスを通じてユーザーをバックエンドのユースケースに接続します。 現在のネイティブ フロントエンド タイプは次のとおりです。 Blazor ウェブアプリ、管理アプリケーション、パブリック ポータル、バック オフィス、パートナー領域、ドメイン固有のインターフェイス用に用意されています。

lino web-app new --name <WebAppName>

このコマンドは、Lino プロジェクト内で実行する必要があります。 Web アプリの名前を要求し、Blazor Web アプリ テンプレートを使用し、選択されたデータを確認し、必要なファイルを作成して、フロントエンドをソリューションに接続するコマンドを実行します。 正規形は次のとおりです web-app。エイリアス webapp そして web 生産性のために存在しますが、ドキュメントと例を優先する必要があります lino web-app new 一貫性を保つため。

何が生成されるのか

Lino によって生成される Blazor Web App は、単なる画面ファイルの集まりではありません。同じ .NET ソリューションに組み込まれ、バックエンドで使われるモジュール構成に従い、ホスト、クライアント、共有コンポーネント、サービスまたはモジュールごとの UI プロジェクトの責任を分離します。

• サーバープロジェクト: Blazor Web アプリをホストし、ルート コンポーネントをマップし、サービスのデフォルト、静的アセット、偽造防止、HTTPS、MudBlazor サービス、および対話型レンダリング モードを構成します。
• クライアントプロジェクト: WebAssembly 側で実行されるコンポーネント、ルーティング、レイアウト、メニュー構造、ブラウザ設定、ローカリゼーション機能、および MudBlazor との統合が集中しています。
• 共有 WebApps プロジェクト: 共通の UI リソース、通知、ダイアログ、クエリ文字列テンプレート、クライアント結果、カルチャ/タイム ゾーン サービス、および再利用可能なコンポーネントを一元化します。
• サービス別、モジュール別のUIデザイン: ソリューションにサービスとモジュールがある場合、Lino は Web アプリ フレームワーク内にフロントエンド プロジェクトを作成し、コンテキスト分離されたページ、メニュー、リソースを維持します。

生成されたホストレジスタ AddInteractiveServerComponents そして AddInteractiveWebAssemblyComponents。 ルートコンポーネント HeadOutlet そして Routes 使用 InteractiveAutoこれにより、アプリケーションはサーバー経由で対話的に起動し、クライアント ランタイムが利用可能になったときに WebAssembly に移行できるようになります。

バックエンド API との統合

Web アプリが存在する場合、Lino は、フロントエンドによる型指定された消費に備えてバックエンドを準備し続けます。 サービスとモジュールはプロジェクトを受け取ることができます Api.Contracts そして Api.Client、リクエスト/レスポンスコントラクトと型指定されたクライアントを生成されたエンドポイントに公開します。

• UI では、機能ごとに生の HTTP 呼び出しを手動で組み立てる必要はありません。
• 生成されたページは、型指定された API クライアントを呼び出し、バックエンドとともに作成されたリクエストおよびレスポンス モデルを操作します。
• モデルの共有 ClientResult、 QueryParams そして PagedQueryParams 結果の処理、フィルター、ページネーション、視覚的なフィードバックを標準化します。
• 型付き HttpClient による統合により、フロントエンドはソリューションの他の部分で使われるコントラクト、権限、検証メッセージ、カルチャと整合します。

実際の流れは次のとおりです。

Blazor ページ -> 型付き API クライアント -> Minimal API エンドポイント -> Command/Query -> データベース

このパスでは、スタック全体の一貫性が維持されます。ドメイン モデル、ユース ケース、エンドポイント、コントラクト、ローカライズされたインターフェイス、ナビゲーション、および権限は、同じプロジェクト規則に従います。

含まれる UI 機能

生成された Web アプリは、実際のアプリケーションの一般的な懸念事項に対してすでに準備されています。

• コンポーネントのルーティング Routes.razor 生成された。
• MudBlazor に基づくレイアウト、ナビゲーション、およびビジュアル コンポーネント。
• 各サービスまたはモジュールで利用可能なページからのメニューの生成。
• ファイル .resx プロジェクトで構成されているカルチャ内のテキストを検索します。
• 認証機能が有効な場合、認証、トークン ストレージ、保護されたルート、および許可サービスをサポートします。
• 権限依存メニュー。現在のユーザーが必要な権限を持っている場合にのみエントリを表示します。

複数のフロントエンド

1 つのバックエンドで複数の Web アプリをサポートできます。これは、異なる視聴者が異なるナビゲーション、セキュリティ、エクスペリエンス、展開を必要とするが、同じサービス、モジュール、ユースケース、および API を引き続き共有する必要がある場合に便利です。

• 公開ウェブサイト: 顧客、訪問者、またはまだ認証されていないユーザーがアクセスできるページ。
• バックオフィス/管理者: オペレーター、サポート、管理チーム用の内部管理パネル。
• パートナーポータル: パートナー、再販業者、サプライヤー、または運用統合に対するアクセスが制限されています。
• セルフサービスエリア: 独自のメニューと権限を備えた、エンド顧客に焦点を当てたエクスペリエンス。

各フロントエンドは独自のレイアウト、リソース、メニュー、アクセス ルールで進化できますが、バックエンドはサービス、モジュール、ユースケース、契約ごとに編成されたままです。

Webページの生成

エンティティをモデル化し、ユースケースを定義し、コマンド、クエリ、エンドポイント、永続性を生成した後、次のステップは通常、インターフェイスで機能を公開することです。 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>

オプションは対話的に通知することもできます。このコマンドは、グリッドに表示するサービス、モジュール、エンティティ、ターゲット Web アプリ、ページ タイプ、およびプロパティを要求します。 最も一般的なタイプは、 クラッド;エンティティがクエリのみをサポートしている場合、Lino は次のようなページを生成できます。 データグリッド。

使用 page new 画面の最初のバージョンを作成するには、 page edit ページがフィールド、契約、または動作の変更を追跡する必要がある場合、および page list エンティティに対してすでに何が生成されているかを理解するため。

推奨フロー

1. Web アプリを作成または選択します。 lino web-app new。
2. エンティティをモデル化し、ユース ケース、クエリ、コマンド、エンドポイント、API コントラクト、永続化アーティファクトを生成します。
3. 走る lino page new インターフェイスを受け取るエンティティを選択します。
4. グリッド内のフィールドを慎重に選択してください。これらは表示される列となり、クエリ パラメーター、フィルター、ページネーションの設定に役立ちます。
5. AppHost を通じてソリューションを実行し、UI、API、認証、権限、データベース統合を一緒に検証します。

生成された構造

CRUD ページの場合、Lino は、単一の Razor ファイルではなく、完全な Blazor ページ パッケージを作成します。

• リスト、作成、編集、詳細、削除を調整するページまたはインデックスを記録します。
• MudBlazor に基づくグリッド コンポーネント。サーバー側の読み込み、ページネーション、フィルター、クエリ パラメーターのマッピングを備えています。
• 型指定された ViewModel と、作成、更新、ID による取得リクエストをマップするための拡張機能を備えたフォーム コンポーネント。
• タイトル、ラベル、ボタン、検証メッセージ、ローカライズされたインターフェイス テキストのリソース。
• 認証が有効になっている場合、ページ アクセスの検証や条件付きボタンなどの権限チェックが行われます。

エンティティの 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: メイン ページ、分離コード、フォーム コンポーネント、グリッド コンポーネント、拡張機能、およびページ分割されたパラメーター。 現在のバージョンでは、Web アプリ、サービス、モジュールによる機能と組織との明示的な統合が追加されています。

生成されたページの仕組み

このページでは、API に対して生成されたものと同じコントラクトを使用します。グリッドはフィルターとページネーションをリストリクエストに変換します。フォームは ViewModel を作成リクエストまたは更新リクエストに変換します。入力された API クライアントは、対応するエンドポイントに呼び出しを送信します。 エンドポイントは、生成されたコマンドまたはクエリを実行し、入力された応答を UI に返します。

Frontend -> API -> Commands/Queries -> データベース

権限が存在する場合、生成されたコードは、識別子によるリスト、作成、編集、削除、クエリなどの権限もチェックします。 これは、ページへのアクセスとユーザーのアクションの可視性の両方に影響します。

その結果、一貫したフルスタック フローが実現します。ドメイン モデル、ユース ケース、エンドポイント、型指定されたクライアント、ローカライズされた UI、ナビゲーション、およびアクセス許可は、同じ設計規則に従います。 ジェネレーターは繰り返しを減らしますが、コンポーネントは製品の調整、使いやすさ、特定のルールのために編集可能なままです。

多言語インターフェース

Lino によって生成された Web アプリケーションはファイルを使用します .resx ローカライズされたテキストの場合。 これにより、同じ Razor 構造を維持し、アクティブなカルチャに応じてタイトル、ラベル、ボタン、エラー メッセージ、検証テキスト、説明を変更することができます。

ローカライゼーションを見た目の仕上げとして扱うべきではありません。管理ページや運用ポータルでは、用語に一貫性がないため、ビジネス ルールに対する疑念が生じます。 したがって、リソースは UI アーキテクチャの一部であり、ページ、フォーム、グリッド、共有コンポーネントを伴う必要があります。

• 一時的な画面レイアウトに関連付けられた名前を避けて、キーを安定した、説明的で意味重視のキーに保ちます。
• ページやコンポーネント上にハードコーディングされたテキストを避けてください。ラベル、メッセージ、タイトル、パンくずリスト、メニュー、確認用のリソースを使用します。
• 技術用語を確認して、ドキュメント、CLI、API 契約、およびインターフェイス間の一貫性を維持します。
• 予期しないフォールバックや部分的に翻訳された画面を防ぐために、カルチャ間で同じキーのセットを保持します。
• 文字通りの翻訳と製品の適応を分離します。用語をエンド ユーザー向けにローカライズする必要がある場合は、アクションの機能的な意味を維持します。

生成されたページには通常、ページ、フォーム、グリッド レベルでリソースがあります。 この分離により、リスト、編集、検証、およびナビゲーション テキストを混在させることなく、各部分を進化させることができます。

すぐに使える応答性の高い CRUD

生成された CRUD は、リスト、フォーム、API との統合、リソース、ページネーション、フィルター、アクション、コードビハインドなど、画面の反復的な基盤を作成するため、配信を高速化します。 それでも、単なる技術的な足場ではなく、製品エクスペリエンスとしてレビューされる必要があります。

優れた CRUD 画面では、ユーザーがレコードを検索し、現在の状態を理解し、自信を持ってアクションを実行し、障害から回復できるようにする必要があります。 これは、社内のバックオフィス画面と、顧客またはパートナー向けのポータルの両方に当てはまります。

• 意思決定に役立つリスト列を選択してください。オペレーターに何も言わない技術分野を含むグリッドは避けてください。
• 予想されるデータ量とユーザーの主な検索基準に従って、フィルターとページネーションを構成します。
• 検証とエラー メッセージを確認して、実装用語だけでなくドメイン言語で問題を説明します。
• データがない場合、API に時間がかかる場合、または操作が完了しない場合にサイレント画面を回避するために、空、読み込み中、およびクラッシュ状態を確認します。
• 元に戻せない削除と操作を確認し、どのレコードが影響を受けるかを明確にします。
• ローカライズされた通知とメッセージを使用して、保存、編集、削除、または失敗した後に明確なフィードバックを表示します。
• バックエンドとフロントエンドでの許可によってアクションを保護します。ボタンを非表示にするとエクスペリエンスは向上しますが、実際の認証に代わるものではありません。
• 小さな画面、特にアクション メニュー、フィルター、必須フィールド、列の多いグリッドでの応答性をチェックします。

Lino によって生成された開始点は、一貫した統合された基礎として扱われる必要があります。 そこから、チームは視覚的な密度、フィールドの順序、表示ルール、権限、テキストを調整して、実際の製品プロセスを反映します。