.NET MAUIの概要

プラットフォームに関係なく、エンタープライズ アプリの開発者は、次のようないくつかの課題に直面します。

• 時間の経過に伴って変化する可能性があるアプリ要件。
• 新しいビジネス チャンスと課題。
• 開発中の継続的なフィードバック。アプリのスコープと要件に大きな影響を及ぼす可能性があります。

これらを念頭に置いて、時間の経過に伴って簡単に変更または拡張できるアプリを構築することが重要です。 このような適応性を考慮した設計は、アプリの個々の部分を独立して開発し、アプリの残りの部分に影響を与えることなく分離してテストできるアーキテクチャが必要であるため、困難な場合があります。

多くのエンタープライズ アプリは非常に複雑で、複数の開発者を必要とします。 複数の開発者が個別にアプリの異なる部分に対して効果的に作業しながら、各部分をシームレスに組み合わせてアプリに統合できるようなアプリの設計方法を決定することは、大きな課題になる場合があります。

従来の方法でアプリを設計して構築すると、"モノリシック" と呼ばれるアプリになります。このようなアプリは、コンポーネントが明確に分離されておらず、緊密に結合されます。 通常、このモノリシック アプローチでは、アプリ内の他のコンポーネントを破壊せずにバグを解決することが難しく、新しい機能を追加したり、既存の機能を置き換えたりすることが困難な可能性があるため、保守が困難で非効率なアプリが構築されることになります。

これらの課題を効果的に解決する方法は、アプリに簡単に統合できるようにアプリを個別の疎結合コンポーネントに分割することです。 このようなアプローチには、次のような利点があります。

• さまざまな個人またはチームで、個々の機能の開発、テスト、拡張、保守を行うことができます。
• 再利用が促進され、認証やデータ アクセスなどのアプリの水平方向の機能と、アプリ固有のビジネス機能などの垂直方向の機能との間で懸念事項が明確に分離されます。 これにより、アプリ コンポーネント間の依存関係と相互作用をより簡単に管理できます。
• さまざまな個人またはチームが、専門知識に従って特定のタスクや機能に集中できるようにすることで、役割分担を維持するのに役立ちます。 特に、ユーザー インターフェイスとアプリのビジネス ロジックをより明確に分離できます。

ただし、アプリを個別の疎結合コンポーネントに分割する場合、解決する必要がある問題が数多くあります。 これには以下が含まれます。

• ユーザー インターフェイス コントロールとそのロジックの間で懸念事項を明確に分離する方法を決定します。 .NET MAUIエンタープライズ アプリを作成する際の最も重要な決定事項の 1 つは、ビジネス ロジックを分離コード ファイルに配置するかどうか、またはユーザー インターフェイス コントロールとそのロジックの間で懸念事項を明確に分離してアプリの保守性とテストの容易性を高めるかどうかです。 詳細については、Model-View-ViewModelに関するページを参照してください。
• 依存関係挿入コンテナーを使用するかどうかを決定します。 依存関係挿入コンテナーは、依存関係が挿入されたクラスのインスタンスを構築し、コンテナーの構成に基づいて有効期間を管理する機能を提供することで、オブジェクト間の依存関係の結合を削減します。 詳細については、依存性の注入に関するページを参照してください。
• オブジェクトと型の参照でリンクするには不便なコンポーネント間で、プラットフォーム提供のイベント処理と疎結合メッセージ ベースの通信のどちらを行うかを選択します。 詳細については、「疎結合コンポーネント間の通信」を参照してください。
• ナビゲーションを呼び出す方法やナビゲーション ロジックが存在する場所など、ページ間の移動方法を決定します。 詳細については、「ナビゲーション」を参照してください。
• ユーザー入力の有効性を検証する方法を決定します。 この決定には、ユーザー入力を検証する方法と、検証エラーについてユーザーに通知する方法が含まれている必要があります。 詳細については、検証に関するページを参照してください。
• 認証を実行する方法と、承認を使用してリソースを保護する方法を決定します。 詳細については、認証と承認 を参照してください。
• データを確実に取得する方法やデータをキャッシュする方法など、Web サービスからリモート データにアクセスする方法を決定します。 詳細については、「リモート データへのアクセス」を参照してください。
• アプリのテスト方法を決定します。 詳細については、「単体テスト」を参照してください。

このガイドでは、これらの問題に関するガイダンスを提供し、NET MAUIを使用してクロスプラットフォーム エンタープライズ アプリを構築するためのコア パターンとアーキテクチャに焦点を当てます。 このガイダンスは、一般的な .NET MAUI エンタープライズ アプリの開発シナリオに対処し、Model-View-ViewModel (MVVM) パターンのサポートを通じてプレゼンテーション、プレゼンテーション ロジック、エンティティに関する懸念事項を分離することによって、適応性、保守性、テストの容易性を備えたコードを生成できるようにすることを目的としています。

サンプル アプリケーション

このガイドには、サンプル アプリケーション eShop が含まれています。これは、次の機能を含むオンライン ストアです。

• バックエンド サービスに対する認証と承認。
• 商品のカタログを閲覧。
• カタログのフィルター処理。
• カタログからの商品の注文。
• ユーザーの注文履歴の表示。
• 設定の構成。

サンプル アプリケーションのアーキテクチャ

サンプル アプリケーションのアーキテクチャの概要を次に示します。

サンプル アプリケーションには次のものが含まれています。

• .NET Aspire のアプリ ホスティングとオーケストレーション
• ASP.NET Core で開発された Blazor Web アプリケーション。
• iOS、Android、Mac Catalyst を使用する macOS、Windows をサポートする、.NET MAUI で開発されたマルチプラットフォーム アプリ。

サンプル アプリケーションには、次のバックエンド サービスが含まれています。

• ID マイクロサービス。これは ASP.NET Core Identity と IdentityServer を使用します。
• カタログ マイクロサービス。これは、データ ドリブンの作成、読み取り、更新、削除 (CRUD) サービスであり、EntityFramework Core を使って SQL Server データベースを使用します。
• 注文マイクロサービス。これは、ドメインドリブンの設計パターンを使用するドメインドリブン サービスです。
• バスケット マイクロサービス。これは、Redis Cache を使用するデータドリブンの CRUD サービスです。

これらのバックエンド サービスは、ASP.NET Core を使用してマイクロサービスとして実装され、.NET Aspire で一意のコンテナーとしてデプロイされます。 これらのバックエンド サービスは総称して、eShop 参照アプリケーションと呼ばれます。 クライアント アプリは、Representational State Transfer (REST) Web インターフェイスを介してバックエンド サービスと通信します。 マイクロサービスとコンテナーの詳細については、「コンテナー化されたマイクロサービス」を参照してください。

マルチプラットフォーム アプリ

このガイドでは、.NET MAUI を使用したクロスプラットフォーム エンタープライズ アプリの構築に焦点を当て、例として eShop マルチプラットフォーム アプリを使用します。 次の図は、前に説明した機能を提供する eShop マルチプラットフォーム アプリのページを示しています。

このマルチプラットフォーム アプリは、eShop 参照アプリケーションによって提供されるバックエンド サービスを使用します。 ただし、バックエンド サービスのデプロイを避けたいユーザーのために、モック サービスのデータを使用するように構成できます。

eShop マルチプラットフォーム アプリは、次の .NET MAUI 機能を実行します。

• XAML
• コントロール
• バインド
• コンバーター
• スタイル
• アニメーション
• コマンド
• 動作
• トリガー
• 効果
• カスタム コントロール

この機能の詳細については、.NET MAUI ドキュメントを参照してください。

さらに、eShop モバイル アプリでは、一部のクラスの単体テストも提供されます。

マルチプラットフォーム アプリ ソリューション

eShop マルチプラットフォーム アプリ ソリューションでは、ソース コードとその他のリソースが複数のプロジェクトに整理されます。 すべてのコア モバイル コンポーネントが、eShopContainers という名前の単一プロジェクトに含まれます。 これは .NET 6 で導入された機能であり、1 つのプロジェクトで複数の出力をターゲットにすることができ、Xamarin.Forms および以前の .NET バージョンで使用していた複数のプラットフォーム プロジェクトを使用する必要がなくなります。 単体テスト用に追加のプロジェクトが含まれます。

このプロジェクトでは、すべてのコンポーネントが単一のプロジェクトに格納されますが、ニーズに基づいて複数のプロジェクトに分割することを検討する価値はあります。 たとえば、独自の依存関係を持つサービスに基づくサービス プロバイダーの実装が複数ある場合、それらのサービス プロバイダーの実装を独自の個別のプロジェクトに分割することが理にかなっている可能性があります。 プロジェクトの分離の適切な候補としては、共有モデル、サービス実装、API クライアント コンポーネント、データベース、またはキャッシュ レイヤーが挙げられます。 企業が別のプロジェクトでコンポーネントを再利用できると思われる場所は、分離の候補になる可能性があります。 これらのプロジェクトは、配布やバージョン管理を容易にするために、NuGet を使用してパッケージ化できます。

すべてのプロジェクトでは、フォルダーを使用して、ソース コードや他のリソースをカテゴリに整理します。 eShop マルチプラットフォーム アプリのクラスは、ほとんどまたはまったく変更することなく任意の .NET MAUI アプリで再利用できます。

eShop プロジェクト

eShop プロジェクトには次のフォルダーが含まれます。

まとめ

Microsoft のクロスプラットフォーム マルチプラットフォーム アプリ開発のツールとプラットフォームは、B2E、B2B、B2C モバイル クライアント アプリ向けの包括的なソリューションを提供し、すべてのターゲット プラットフォーム (iOS、macOS、Android、Windows) 間でコードを共有できるようになり、総保有コストの削減に役立ちます。 アプリでは、ネイティブ プラットフォームの外観を維持しながら、ユーザー インターフェイスとアプリ ロジック コードを共有できます。

エンタープライズ アプリの開発者は、開発中にアプリのアーキテクチャを変更する可能性があるいくつかの課題に直面します。 このため、時間の経過に伴ってアプリを変更または拡張できるようにアプリを構築することが重要です。 このような適応性を考慮した設計は困難な場合がありますが、通常は、アプリに簡単に統合できるようにアプリを個別の疎結合コンポーネントに分割します。