分割されたモデル
この記事では、スタックを 3 つの主要モデル (アプリケーション プラットフォーム、アプリケーション基準、アプリケーション スイート) に分割する方法について説明します。
概要
モジュール コードを開発することは、モデル分割の原動力です。 複数のモデルにスタックを分割すると、コンパイル時間の短縮、運用環境でのパートナー IP の適切な区別など、多くの利点が提供されます。 メイン モデルは、アプリケーション プラットフォーム、アプリケーション基盤、アプリケーション スイートの 3 つがあります。
アプリケーション プラットフォームは最下位モデルであり、カーネルとやり取りする最下位レベルの要素が含まれています。 アプリケーション オブジェクト サーバー (AOS) は、 アプリケーション プラットフォーム を使用してのみ起動できます。 アプリケーション基盤は、アプリケーション プラットフォームの一番上に配置され、すべてのアプリケーションによって共有されるフレームワーク機能を含みます。 最後に、アプリケーション スイートはアプリケーション基準の上部に位置し、アプリケーションの特定要素を含みます。 付録のモデル内訳表は、これらの各モデルのコンポーネントの例を示します。 各モデルは、独自のアセンブリにコンパイルされ、下位レイヤー モデル アセンブリに依存します。 アプリケーション プラットフォームは、他のモデルには依存しません。 これは、モデルをアセンブリに直接マッピングすることを意味します。
モジュール スタックで開発することで、アプリケーション スイートで変更を行い、残りのスタックに触れることなくコンパイルすることができます。 新しい変更のあるモデルのみコンパイルされる必要があり、コンパイルの時間が大幅に短縮されます。 詳細については、この記事の終わりにある「モデルの内訳」セクションで確認できます。
モデルのカスタマイズ
カスタマイズの方法には、オーバーレイと拡張の 2 種類があります。 オーバーレイヤーにより、下位レベルでモデル内の要素を変更、つまりオーバーレイする複数のレイヤーに変更を加えることができます。 拡張子を使用すると、要素のイベントやプラグイン ポイントに新しい要素を追加したり、コードをアタッチすることができます。 使用されるカスタマイズのタイプは、モデルがどのようにコンパイルされ、最終的にパッケージ化されるかに影響を与えます。 1 つ以上のモデルが、アセンブリにコンパイルされます。 アセンブリ、非コード メタデータ、およびそれをコンパイルされたコンポーネントはパッケージを形成します。 パッケージは、独立した配置可能な単位です。 拡張機能のカスタマイズのみが含まれるモデルは、独自のアセンブリにコンパイルして独自のパッケージに配置できます。 任意のオーバーレイが含まれるモデルは、オーバーレイ モデルに基づいてアセンブリにコンパイルする必要があります。
拡張機能の使用には、以下を含むいくつかの利点があります。
- アプリケーション ライフ サイクル管理の目的で、拡張コンポーネントのみを管理する必要があります。
- カスタマイズの構築ではアプリケーション全体を再コンパイルする必要はありません。
- クラウドで Microsoft はユーザーのカスタマイズに影響を与えずに、インストール、パッチ、アップグレード、および内部 API の変更を行えます。
- 他のカスタマイズを意識せずに、ソリューションを別々に処理することができます。
現在、コード拡張、テーブル拡張、フォーム拡張、メニュー拡張、列挙拡張がサポートされています。 拡張機能およびオーバーレイによるカスタマイズ と 拡張機能によるモデル要素のカスタマイズ の拡張機能セクションでは、拡張機能の使い方について詳しく説明しています。 拡張子は、可能な限りサポートされている要素で使用する必要があり、既存の Microsoft コードを変更する必要がない場合に最適です。 メソッドの機能をマスクするための変更には、コード自体を変更するためのオーバーレイが必要です。 オーバーレイヤーは、カスタマイズが基本機能をカスタマイズする場合に、拡張機能がカバーしない領域に存在する必要があります。 次の図は、2 つのカスタマイズ戦略の違いをまとめたものです。
モデルの内訳
| モデル | 概念 |
| アプリケーション プラットフォーム | アプリケーション ロジックに対応するカーネル機能へのアプリケーション プラットフォーム インターフェイス。 AOS は、このモデルだけで開始することができます。
|
| アプリケーション基準 |
|
| Application Suite |
|