1. Liferay SANDBOX
  2. Liferay DXP 7.1開発者用チュートリアル
  3. Webアプリケーションの開発

ドキュメンテーション

モデル、サービス、永続レイヤーの生成

モデル、サービス、永続レイヤーの生成

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

バックエンドの生成

手順2/3

永続レイヤーはモデルデータの保存および取得を行います。 サービスレイヤーは、アプリケーションと永続レイヤーの間のバッファーです。サービスレイヤー内の呼び出し以外を変更することなく、永続レイヤーを異なる実装に置換できます。

ゲストブックとエントリをモデル化するには、ゲストブックとエントリモデルクラスを作成します。 ただし、Javaでこれを直接行うことはありません。 代わりに、オブジェクトモデルを生成し、Liferay DXPがサポートするすべてのSQLデータベースにそれをマップするサービスビルダーで、それらを定義します。

このアプリケーションの設計では、それぞれが異なるエントリセットを含む複数のゲストブックを使用できます。 アプリケーションにアクセスする権限を持つすべてのユーザーはエントリを追加できますが、ゲストブックを追加できるのは管理ユーザーだけになります。

それでは、始めましょう。 最初にGuestbookエンティティを作成します。

  1. guestbook-serviceプロジェクトで、service.xmlを開きます。 その際、Sourceタブが選択されていることを確認してください。

  2. Liferay Dev Studio DXPがプロジェクトを生成すると、このファイルはダミーのエンティティで埋められ、置き換えられます。 最初に、ファイルの開始コンテンツ（DOCTYPE 以下）を次のコードに置き換えます。

    <service-builder auto-namespace-tables="true" package-path="com.liferay.docs.guestbook"><author>liferay</author>
    <namespace>GB</namespace> <entity name="Guestbook" local-service="true" uuid="true">

    これは、作成者、名前空間、およびエンティティ名を定義しています。 名前空間は、データベースフィールド名と矛盾しないようにします。 最後のタグは、Guestbookエンティティ定義の開始タグです。 このタグでは、エンティティのローカルサービスを有効にし、その名前を定義して、universally unique identifier (UUID)を持つように指定します。

  3. 次に、PKフィールドセクションを置き換えます。

    <column name="guestbookId" primary="true" type="long" />

    これにより、タイプlongのエンティティのプライマリキーとして、guestbookIdが定義されます。

  4. グループインスタンスはそのまま残しておけます。

    <column name="groupId" type="long" />

    これは、エンティティインスタンスが属するLiferay DXPのサイトIDを定義します（これについては後ほど説明します）。

  5. 監査フィールドセクションはデフォルトのままにします。 状態フィールドを追加してください。

    <!-- Status fields -->

<column name="status" type="int" />
<column name="statusByUserId" type="long" />
<column name="statusByUserName" type="String" />
<column name="statusDate" type="Date" />

    監査セクションでは、Liferay DXPメタデータを定義します。 companyIdは、 ポータルインスタンスのプライマリキーです。 userIdはユーザーのプライマリキーです。 createDateおよび modifiedDateは、エンティティインスタンスが作成および変更されるそれぞれの日付を格納します。 状態セクションは後でワークフローを実装するために使用されます。

  6. その他のフィールドセクションで、生成されたフィールドを次のフィールドに置き換えます。

     <column name="name" type="String" />

  7. 次に、ゲストブックエンティティから他のすべてを削除します。 末尾</entity>タグの前に、このファインダー定義を追加します。

        <finder name="GroupId" return-type="Collection">
        <finder-column name="groupId" />
    </finder>

    ファインダーは、ゲストブックエンティティを取得するために使用するgetメソッドを生成します。 ファインダーによって使用されるフィールドは、取り出されるデータの範囲を定義します。 このファインダーは、アプリケーションが存在するサイトに対応するgroupIdで、すべてのゲストブックを取得します。 これにより、管理者はゲストブックを複数のサイトに配置でき、各Guestbookで、そのサイトを対象とする独自のデータを持つことができます。

Guestbookエンティティはこれで完成です。 次に、 Entryエンティティを作成します。

  1. 開始エンティティタグを追加します。

    <entity name="Entry" local-service="true" uuid="true">

    Guestbookエンティティと同様に、ローカルサービスを有効にし、エンティティの名前を定義して、UUIDが必要であることを指定します。

  2. タグを追加して、主キーとgroupIdを定義します。

    <column name="entryId" primary="true" type="long" />

<column name="groupId" type="long" />

  3. Guestbookエンティティのフィールドに、一致する監査フィールドを追加します。

    <column name="companyId" type="long" />
<column name="userId" type="long" />
<column name="userName" type="String" />
<column name="createDate" type="Date" />
<column name="modifiedDate" type="Date" />

  4. ゲストブックで行ったように、状態フィールドを追加します。

     <!-- Status fields -->

 <column name="status" type="int" />
 <column name="statusByUserId" type="long" />
 <column name="statusByUserName" type="String" />
 <column name="statusDate" type="Date" />

  5. Entryを定義するフィールドを追加します。

    <column name="name" type="String" />
<column name="email" type="String" />
<column name="message" type="String" />
<column name="guestbookId" type="long" />

    name、email、およびmessageフィールドは、Entryを含みます。 これらのフィールドは、エントリ、メールアドレス、ゲストブックメッセージを作成する人の名前をそれぞれ定義します。 guestbookIdは、記述するコードによって自動的に割り当てられ、Guestbookは外部キーとなります。 これにより、Entryが特定のGuestbookに結び付けられます。

  6. ファインダーと終了エンティティタグを追加します。

        <finder name="G_G" return-type="Collection">
        <finder-column name="groupId" />
        <finder-column name="guestbookId" />
    </finder>
</entity>

    ここでは、groupIdおよびguestbookIdによってゲストブックエントリを取得するファインダーを定義します。 前回と同様に、groupIdは、アプリケーションが存在するサイトに対応します。 guestbookIdは、エントリの元となるゲストブックを定義します。 このファインダーは、エントリーのCollectionを戻します。

  7. <entity>タグの外側、</service-builder>終了タグの直前に、例外タイプを定義します。 EntryEmail EntryMessage EntryName GuestbookName

    これらは、後でtry/catchステートメントで使用する例外クラスを生成します。

  8. service.xmlファイルを保存します。

これで、Service Builderを実行して、モデル、サービス、および永続レイヤーを生成する準備が整いました。!

  1. Dev Studio DXPの右側にあるGradleタスクペインで、guestbook-service → buildを開きます。

  2. buildServiceを右クリックし、Run Gradle Tasksを選択して実行します。 Gradleは最初に実行したときに依存関係をダウンロードするため、インターネットに接続していることを確認してください。

  3. Project Explorerでguestbook-serviceモジュールを右クリックし、Refreshを選択します。 guestbook-apiモジュールに対してこの手順を繰り返します。 これにより、Service Builderによって生成された新しいクラスとインターフェイスがDev Studio DXPに表示されます。

  4. Project Explorerでguestbook-serviceモジュールを右クリックして、Gradle → Refresh Gradle Projectを選択します。 guestbook-apiモジュールに対してこの手順を繰り返します。 これにより、モジュールのGradle依存関係が最新のものになります。

Service Builderは、疎結合と呼ばれる設計哲学に基づいています。 モデル、サービス、および永続レイヤーの、アプリケーションの3つのレイヤーを生成します。 疎結合とは、モデルレイヤーとサービスレイヤーでほとんどまたはまったく変更せずに、永続レイヤーを交換できるということを意味します。 モデルは-apiモジュールにあり、サービスレイヤーと永続レイヤーは-serviceモジュールにあります。

図1：モデル、サービス、および永続レイヤーは疎結合設計で構成されています。

各レイヤーは、Javaインターフェイスとそれらのインターフェイスの実装を使用して実装されます。 モデルを表すEntryクラスを持つのではなく、Service BuilderはGuestbookインターフェイス、サービスビルダーが管理するGuestbookBaseImpl抽象クラス、およびカスタマイズ可能なGuestbookImplクラスを含むクラスのシステムを生成します。 この設計により、モデルをカスタマイズすることができますが、サービスビルダーは作成が面倒なコードを生成します。 これが、サービスビルダーがコードジェネレーター嫌いのコードジェネレーターである理由です。

次に、サービス実装を作成します。

« 本サービスビルダーとはサービスメソッドの実装 »
この記事は役に立ちましたか？
0人中0人がこの記事が役に立ったと言っています