依存関係の活用

依存関係の活用

ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

モジュールは、OSGiマニフェストを使用して、消費および共有するJavaパッケージを宣言します。 マニフェストの インポートパッケージ および エクスポートパッケージ 設定は、この情報を公開します。 特定のモジュールを使用するかどうかを決定する際、そのモジュールが提供するものと依存するものを事前に把握します。 Java EEを改良したものとして、OSGiは依存関係の推測を取り除きます。

チュートリアルのこの部分では次を説明します。

Liferay DXP 7.1で依存関係がどのように機能するかを学習することから始めましょう。

依存関係の仕組み

各モジュールのマニフェストには、モジュールが依存するパッケージがリストされます。 Gradle、Maven、Ant / Ivyなどのビルド環境を使用して、各パッケージのモジュールに依存関係を設定できます。 ビルド時に、依存関係フレームワークは依存関係チェーン全体を検証し、新しく指定されたすべてのモジュールをダウンロードします。 実行時にも同じことが起こります。OSGiランタイムは、どのモジュールが他のどのモジュールに依存しているかを正確に認識します(依存関係が満たされていない場合、高速に失敗します)。 依存関係管理は明示的であり、事前に自動的に実施されます。

バージョン管理は、各モジュールとそのエクスポートされたパッケージに対して独立しています。 エクスポートするモジュールのバージョンに応じて、特定のパッケージバージョンを使用できます。 また、必要なバージョンのモジュールを自由に組み合わせて使用できます(ただし、「大きな力には大きな責任が伴います」ということを忘れないでください。 )。

すべてのモジュールで、Liferay DXPは セマンティックバージョニング使用し

。 API作成者は、依存するコンシューマーとAPI実装に関連するため、パッケージまたはモジュールのプログラム互換性を自動的に伝えることができる標準です。 パッケージは、(Liferayのワークスペースから作成したプロジェクトで使用される(すなわち、意味的に)プロジェクトと互換性がない、BNDプログラムである場合は Liferayのプロジェクトテンプレート)すぐにそのプロジェクトのビルドに失敗します。 bndを使用しない開発者は、各依存関係モジュールのマニフェストでパッケージのバージョンを手動で確認できます。

セマンティックバージョニングは、依存するパッケージとモジュールのバージョン範囲を柔軟に指定することもできます。 つまり、アプリのパッケージの複数のバージョンが機能する場合、それらのいずれかを使用するようにアプリを構成できます。 さらに、bndは、モジュールが依存する各パッケージの意味的に互換性のある範囲を自動的に決定し、その範囲をモジュールのマニフェストに記録します。

プロジェクトをテストすると、依存関係パッケージの新しいバージョンにバグがあったり、動作が異なることがあります。 問題ない。 パッケージのバージョン範囲を調整して、不要なバージョンまで含めることができます。

次に、既存のアプリをモジュール化するタイミングと、モジュールを組み合わせてアプリを作成するタイミングを検討します。

依存関係はモジュール開発を促進します

Liferay DXPの依存関係とセマンティックバージョン管理のサポートにより、モジュール開発が促進されます。 依存関係フレームワークを使用すると、モジュールを使用してモジュールをリンクできます。 これらのモジュールを組織全体で使用して、他の人に配布できます。 Liferayの依存関係管理との統合により、既存のアプリをモジュール化し、モジュールを組み合わせたアプリを開発できます。 Liferayでアプリを開発するための強力で楽しい方法です。

既存のアプリをモジュール化する際に考慮すべきいくつかの一般的な手順は次のとおりです。

  1. アプリ全体を単一のモジュールに配置することから始めます:これは、Liferayのモジュールフレームワークを理解するための最小限の最初のステップです。 Liferay Workspace、Gradle、Maven プロジェクトなど、選択した環境でアプリをビルド、デプロイ、テストするときに自信がつきます。

  2. フロントエンドをバックエンドから分割する:フロントエンドポートレットとサーブレット、およびバックエンド実装( Service Builder またはOSGiコンポーネントなど)をモジュール化することは、論理的な次のステップです。 これにより、各コード領域が個別に進化し、さまざまな実装が可能になります。

  3. 必須ではない機能をモジュールに抽出します:アプリのコアコードベースに結び付けられる必要のない機能またはAPI拡張機能がある場合があります。 これらは、提供するAPIを実装する独立したモジュールとしてリファクタリングできます。 例としては、サードパーティシステムへのコネクタや、さまざまなデータのエクスポート/インポート形式のサポートがあります。

上記の原則は、新しいモジュールベースのアプリの開発にも適用されます。 アプリを設計するとき、その機能、フロントエンド、およびバックエンドに関して、実装のバリエーションを検討してください。 APIを使用してバリエーションをカプセル化します。 次に、APIと実装を個別のモジュールとして開発します。 依存関係を使用してそれらを一緒に配線できます。

LiferayのBlogsアプリケーション は、前述の方法でモジュール化を例示しています。

API

  • blogs-api コア実装をカプセル化します

バックエンド

  • blogs-service 実装 blogs-api

フロントエンド

  • blogs-web アプリのUIを提供します

必須ではない機能と拡張機能

  • blogs-editor-configuration エディターを拡張するために ポータルカーネル モジュールを拡張します

  • blogs-recent-bloggers-web -Recent Bloggersアプリを提供します

  • blogs-item-selector-api アイテムセレクターの実装をカプセル化します

  • blogs-item-selector-web ブログアプリのアイテムセレクターをレンダリングします

  • blogs-layout-prototype ブログエントリを紹介するページテンプレートを作成します

ブログアプリは、多くのモジュラーアプリと同様に、関心事をモジュールに分けます。 このように、フロントエンド開発者はフロントエンドコードに専念し、バックエンド開発者はそのコードに専念します。 これらの論理的な境界により、開発者はモジュールを個別に設計、実装、およびテストできます。

アプリ中心のモジュールを開発するとき、アプリにバンドルすることを検討できます(Liferay Marketplaceアプリの一部としてなど)。 アプリの一部としてそれらを含めることは、消費者にとって便利です。 ただし、モジュールをアプリにバンドルすることにより、アプリのリリーススケジュールを守ることになります。 つまり、アプリのモジュールの新しいバージョンを直接デプロイすることはできません。アプリの次のリリースの一部としてモジュールをリリースする必要があります。

これまで、依存関係とセマンティックバージョニングの仕組みを学習しました。 既存のアプリをモジュール化し、新しいモジュールアプリを作成するためのガイドラインを検討しました。 ここで、OSGiとモジュール性を取り巻く勢いを増すために、OSGi宣言サービスを使用した OSGiサービスと依存性注入を調べてください。

関連トピック

依存関係の構成

パッケージのインポート

パッケージのエクスポート

« OSGiとモジュール性OSGiサービスと宣言型サービスによる依存性注入 »
この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています