Pendekatan apa dalam Pola DataMapper yang lebih baik untuk beberapa tabel atau bergabung?

Biasanya, Data Mapper memetakan data dari satu tabel tertentu. (Secara teoritis seharusnya berkomunikasi antara Storage dan Objek Domain, tetapi tidak mungkin dalam kasus saya, jadi saya langsung berkomunikasi dengan tabel.)

Table1Mappper> Table1

Tetapi jika tabel itu membutuhkan data untuk bergabung dari tabel lain, maka Anda memperluas ruang lingkup Pemeta Data Anda yang seharusnya hanya memetakan dari satu tabel.

Table1Mapper> Table1: inner-join: Table2

Bukankah lebih baik jika Table2 memiliki mapper sendiri Table2Mapperuntuk memetakan datanya?

Jika Anda berpikir Yes, maka jika Anda ingin menampilkan daftar catatan dari Table1Mapper dan kemudian menggunakan Table2Mapper untuk mendapatkan data yang seharusnya digabungkan, Anda akan menjalankan kueri dalam satu lingkaran, yang juga tidak bagus.

Apa wawasan Anda tentang hal ini?

Cara lain adalah mengubah mapper Anda untuk menangani sub tabel?

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

Yang menurut saya baik-baik saja, tetapi hanya sampai ruang lingkup seluruh mapper berurusan satu entitas tertentu dalam aplikasi. Sebagai contoh postdan post_author. Tetapi jika cakupannya berbeda seperti postdan gallery, di atas tidak akan memberikan data mapper yang ideal. Untuk menggambarkan hal ini

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

Apa tidak benar kan? Tetapi bagaimanapun Anda ingin mengambil galeri dari satu posting dalam satu query, karena menambahkan overhead query dalam satu loop bukanlah kinerja solusi yang baik.

Menurut Anda apa cara yang tepat untuk menyelesaikan masalah ini dalam Pola DataMapper / atau pola lainnya jika memiliki cara yang lebih baik dalam menangani kasus-kasus seperti itu?

Dengan Data Mapper yang Anda maksud adalah yang dijelaskan oleh Martin Fowler , bukan? Ini adalah salah satu pola Pola Arsitektur Sumber Data. Lainnya adalah:

• Tabel Data Gateway
• Gateway Data Baris
• Rekaman Aktif

Data Mapper berbeda dari pola lain sehubungan dengan hubungan antara objek dan tabel. Kedua pola Gateway Data dan pola Rekaman Aktif mengasumsikan pemetaan hampir satu ke satu dari tabel ke objek.

Mari kita lihat sebuah contoh:

table BANK_ACCOUNT
   ID

table BANK_ACCOUNT_BALANCE
   ID
   BANK_ACCOUNT_ID
   BALANCE_AMOUNT
   DATE

Objek domain adalah:

class BankAccount {
    long id;
}

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

Seperti yang Anda lihat pemetaan satu-ke-satu antara kelas dan tabel. Ada juga dua Gateway Data Tabel / Baris yang berbeda atau Rekaman Aktif - satu untuk setiap tabel.

Sebaliknya, Data Mapper memungkinkan untuk tipuan :

Lapisan Pemetaan (473) yang memindahkan data antara objek dan database sambil menjaga mereka independen satu sama lain dan mapper itu sendiri.

Jadi ketika Anda menggunakan Data Mapper, objek Anda bisa berbeda dari tabel basis data. Anda bebas untuk memperkenalkan agregasi, bergabung dengan tabel lain, melakukan operasi aritmatika, memperkenalkan hierarki warisan. Jadi, jawab pertanyaan Anda - tidak apa-apa untuk bergabung dengan dua tabel di Data Mapper selama objek hasil adalah objek domain yang valid.

Dalam contoh kita, kita dapat memiliki:

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

sebagai objek domain dikembalikan oleh Pemeta Data tunggal berdasarkan BERGABUNG dan agregasi.

Oleh karena itu, Data Mapper sangat cocok untuk mewakili model domain non-sepele. Jika model domain Anda agak sederhana, Anda dapat mempertimbangkan untuk menggunakan pola Rekaman Aktif atau Gateway Data.

Need for JOINs Data Mapper kadang-kadang (tetapi tidak harus) menunjukkan bahwa kelas domain terlalu kompleks. Silakan periksa Prinsip Tanggung Jawab Tunggal , Prinsip Pemisahan Antarmuka .

Dalam domain-Driven Design domain kelas (yaitu dikembalikan oleh Data Mapper) berupa entitas atau objek nilai. Buku DDD menggambarkan dengan baik apa yang harus dimiliki oleh suatu entitas. Anda mungkin ingin memeriksa ini.

Selain itu DDD mendefinisikan Agregat (dijelaskan dengan sangat baik di sini ). Mereka sering dimuat bersama. Bergabung dengan dua tabel mungkin menyarankan bahwa ada dua entitas dalam agregat tunggal.