DataMapperパターンのどのアプローチが複数のテーブルまたは結合されたテーブルに適していますか？

通常、Data Mapperは1つの特定のテーブルのデータをマップします。（理論的には、ストレージとドメインオブジェクトの間で通信する必要がありますが、私の場合は不可能なので、テーブルと直接通信しています。）

Table1Mappper> Table1

ただし、そのテーブルで別のテーブルからデータを結合する必要がある場合は、1つのテーブルからのマッピングのみを想定していたデータマッパーのスコープを拡張します。

Table1Mapper> Table1：inner-join：Table2

Table2がTable2Mapperデータをマップする独自のマッパーを持っていれば、もっと良いのではないでしょうか？

考えた場合Yes、Table1Mapperからレコードのリストを表示し、後でTable2Mapperを使用して、結合されるはずだったデータを取得したい場合は、ループでクエリを実行することになりますが、どちらも適切ではありません。

この方法について、どのような洞察がありますか？

別の方法は、サブテーブルを処理するようにマッパーを変更することですか？

class Table1Mapper {
    public main_table = 'table1';
    public sub_table1 = 'table2';
}

これは問題ないと思いますが、マッパー全体のスコープがアプリケーション内の1つの特定のエンティティを処理するまでのみです。たとえばpostとpost_author。しかし、postおよびのようにスコープが異なる場合、gallery上記は理想的なデータマッパーを提供しません。これを説明するには

class PostMapper {
     public table_name = 'tbl_post';
     public gallery_table_name = 'tbl_gallery';
}

正しくありませんか？ただし、1つのクエリで1つの投稿のギャラリーを取得する必要があります。ループでクエリのオーバーヘッドを追加することは、優れたソリューションパフォーマンスではないためです。

このようなケースを処理するより良い方法がある場合、DataMapperパターンまたは他のパターンでこれを解決する正しい方法は何だと思いますか？

データマッパーとは、Martin Fowlerによって記述されたものを意味しますよね？これは、Data Source Architectural Patternsパターンの1つです。その他は次のとおりです。

• テーブルデータゲートウェイ
• 行データゲートウェイ
• アクティブレコード

Data Mapperは、オブジェクトとテーブルの関係が他のパターンと異なります。データゲートウェイパターンとアクティブレコードパターンはどちらも、テーブルからオブジェクトへのほぼ1対1のマッピングを想定しています。

例を見てみましょう：

table BANK_ACCOUNT
   ID

table BANK_ACCOUNT_BALANCE
   ID
   BANK_ACCOUNT_ID
   BALANCE_AMOUNT
   DATE

ドメインオブジェクトは次のとおりです。

class BankAccount {
    long id;
}

class BankAccountBalance {
    long id;
    long bankAccountId;
    Decimal balanceAmount;
    Date date;
}

ご覧のとおり、クラスとテーブル間の1対1のマッピングです。2つの異なるテーブル/行データゲートウェイまたはアクティブレコードもあります-各テーブルに1つ。

対照的に、Data Mapperは間接参照を可能にします。

オブジェクトとデータベース間でデータを移動する一方で、それらを相互に独立させ、マッパー自体を維持するマッパー（473）のレイヤー。

したがって、Data Mapperを使用している場合、オブジェクトがデータベーステーブルと異なる可能性があります。集計の導入、他のテーブルとの結合、算術演算の実行、継承階層の導入は自由です。したがって、あなたの質問に答えてください-結果オブジェクトが有効なドメインオブジェクトである限り、Data Mapperで2つのテーブルを結合することは完全に問題ありません。

この例では、次のようになります。

class BankAccount {
    long id;
    Decimal latestBalance;
    Date latestBalanceDate;
}

JOINと集計に基づいて単一のデータマッパーによって返されるドメインオブジェクトとして。

したがって、Data Mapperは重要なドメインモデルを表すのに最適です。ドメインモデルがかなり単純な場合は、アクティブレコードパターンまたはデータゲートウェイの使用を検討してください。

JOINの必要性Data Mapperは、ドメインクラスが複雑すぎることを示す場合があります（必須ではありません）。単一責任の原則、インターフェース分離の原則を確認してください。

ドメイン駆動設計では、ドメインクラス（つまり、データマッパーによって返される）は、エンティティまたは値オブジェクトの形式をとります。DDDブックは、エンティティが何を構成する必要があるかをかなりよく説明しています。これをチェックしてみてください。

さらに、DDDは集約を定義します（ここでかなり詳しく説明されています）。彼らはしばしば一緒に読み込まれます。2つのテーブルを結合すると、単一の集計に2つのエンティティがあることが示唆される場合があります。