Apa perbedaan antara Data Mapper, Table Data Gateway (Gateway), Data Access Object (DAO) dan pola Repositori?

Saya mencoba memoles keterampilan pola desain saya, dan saya ingin tahu apa perbedaan antara pola-pola ini? Semuanya tampak seperti hal yang sama - merangkum logika basis data untuk entitas tertentu sehingga kode panggilan tidak memiliki pengetahuan tentang lapisan kegigihan yang mendasarinya. Dari penelitian singkat saya, mereka semua biasanya menerapkan metode CRUD standar Anda dan mengaburkan detail spesifik basis data.

Terlepas dari konvensi penamaan (mis. CustomerMapper vs CustomerDAO vs. CustomerGateway vs. CustomerRepository), apa bedanya, jika ada? Jika ada perbedaan, kapan Anda akan memilih yang satu dari yang lain?

Di masa lalu saya akan menulis kode yang mirip dengan yang berikut ini (disederhanakan, tentu saja - saya biasanya tidak menggunakan properti publik):

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

dan memiliki CustomerGatewaykelas yang mengimplementasikan logika basis data khusus untuk semua metode. Kadang-kadang saya tidak akan menggunakan antarmuka dan membuat semua metode pada statis CustomerGateway (saya tahu, saya tahu, yang membuatnya kurang dapat diuji) sehingga saya dapat menyebutnya seperti:

Customer cust = CustomerGateway.GetCustomerByID(42);

Ini tampaknya menjadi prinsip yang sama untuk pola Mapper Data dan Repositori; pola DAO (yang merupakan hal yang sama dengan Gateway, saya kira?) juga tampaknya mendorong gateway khusus basis data.

Apakah saya melewatkan sesuatu? Agak aneh rasanya memiliki 3-4 cara berbeda dalam melakukan hal yang persis sama.

Contoh istilah Anda; DataMapper, DAO, DataTableGateway dan Repository, semua memiliki tujuan yang sama (ketika saya menggunakan satu, saya berharap untuk mendapatkan kembali objek Pelanggan), tetapi maksud / makna yang berbeda dan implementasi yang dihasilkan.

Sebuah Repositori "bertindak seperti koleksi, kecuali dengan kemampuan query yang lebih rumit" [ Evans, Domain Driven Design ] dan dapat dianggap sebagai "objek dalam fasad memori" ( diskusi Repository )

Sebuah DataMapper "memindahkan data antara obyek dan database sekaligus menjaga mereka independen satu sama lain dan mapper itu sendiri" ( Fowler, PoEAA, Mapper )

Sebuah TableDataGateway adalah "Gateway (objek yang merangkum akses ke sistem eksternal atau sumber daya) untuk tabel database. Satu contoh menangani semua baris dalam tabel " ( Fowler, PoEAA, TableDataGateway )

Sebuah DAO "memisahkan antarmuka klien data sumber daya dari mekanisme akses data / menyesuaikan sumber daya data spesifik akses API untuk antarmuka klien generik" yang memungkinkan "mekanisme akses data untuk mengubah secara independen dari kode yang menggunakan data" ( Sun Blueprints )

Repositori tampaknya sangat generik, sehingga tidak ada gagasan tentang interaksi basis data. DAO menyediakan antarmuka yang memungkinkan implementasi basis data yang berbeda untuk digunakan. TableDataGateway secara khusus adalah pembungkus tipis di sekitar satu meja. DataMapper bertindak sebagai perantara yang memungkinkan objek Model untuk berkembang secara independen dari representasi basis data (dari waktu ke waktu).

Ada kecenderungan dalam dunia desain perangkat lunak (setidaknya, saya merasa begitu) untuk menemukan nama-nama baru untuk hal-hal dan pola lama yang terkenal. Dan ketika kita memiliki paradigma baru (yang mungkin sedikit berbeda dari hal-hal yang sudah ada), biasanya disertai dengan serangkaian nama baru untuk setiap tingkatan. Jadi "Logika Bisnis" menjadi "Lapisan Layanan" hanya karena kita mengatakan kita melakukan SOA, dan DAO menjadi Repositori hanya karena kita mengatakan kita melakukan DDD (dan masing-masing itu sebenarnya bukan sesuatu yang baru dan unik sama sekali, tetapi sekali lagi: nama baru untuk konsep yang sudah dikenal dikumpulkan dalam buku yang sama). Jadi saya tidak mengatakan bahwa semua paradigma dan akronim modern ini memiliki arti yang sama persis, tetapi Anda seharusnya tidak terlalu paranoid tentang hal itu. Kebanyakan ini adalah pola yang sama, hanya dari keluarga yang berbeda.

Data Mapper vs Table Gateway Data Untuk membuat cerita panjang pendek:

Kamu punya pendapat bagus. Pilih yang paling Anda kenal. Saya suka menunjukkan beberapa hal yang dapat membantu memperjelas.

Table Data Gateway digunakan terutama untuk satu tabel atau tampilan. Ini berisi semua pilihan, menyisipkan, memperbarui, dan menghapus. Jadi Pelanggan adalah tabel atau tampilan dalam kasus Anda. Jadi, satu instance dari objek gateway data tabel menangani semua baris dalam tabel. Biasanya ini terkait dengan satu objek per tabel database.

Sementara Data Mapper lebih independen dari logika domain apa pun dan kurang digabungkan (meskipun saya percaya ada kopling atau tidak kopling). Ini hanyalah lapisan perantara untuk mentransfer data antara objek dan database sambil menjaga mereka independen satu sama lain dan mapper itu sendiri.

Jadi, biasanya dalam mapper, Anda melihat metode seperti menyisipkan, memperbarui, menghapus dan dalam gateway data tabel Anda akan menemukan getcustomerbyId, getcustomerbyName, dll.

Objek transfer data berbeda dari dua pola di atas, terutama karena itu adalah pola distribusi dan bukan pola sumber data seperti dua pola di atas. Gunakan terutama ketika Anda bekerja dengan antarmuka jarak jauh dan perlu membuat panggilan Anda kurang cerewet karena setiap panggilan bisa menjadi mahal. Jadi biasanya desain DTO yang dapat diserialisasi melalui kawat yang dapat membawa semua data kembali ke server untuk menerapkan aturan bisnis atau pemrosesan lebih lanjut.

Saya tidak berpengalaman dalam pola repositori karena saya tidak mendapatkan kesempatan untuk menggunakan sampai sekarang tetapi akan melihat jawaban orang lain.

Di bawah ini hanya pemahaman saya.

TableGateWay / RowDataGateWay : Dalam konteks ini, Gateway merujuk implementasi spesifik yang memiliki setiap pemetaan "objek domain" ke setiap "gateway objek domain". Sebagai contoh, jika kita memiliki Person , maka kita akan memiliki PersonGateway untuk menyimpan objek domain Person ke database. Jika kita memiliki Orang, Karyawan, Pelanggan, dll, kita akan memiliki PersonGateway, EmployeeGateway, dan CustomerGateway. Setiap gateway akan memiliki fungsi CRUD spesifik untuk objek itu dan tidak ada hubungannya dengan gateway lainnya. Tidak ada kode / modul yang dapat digunakan kembali di sini. Gerbang dapat dibagi lagi menjadi RowDataGateway atau TableGateway, tergantung jika Anda melewatkan "id" atau "objek". Gateway biasanya dibandingkan dengan catatan aktif. Ini mengikat model domain Anda ke skema database.

Repositori / DataMapper / DAO : Mereka adalah hal yang sama. Mereka semua merujuk ke lapisan Persistence yang mentransfer entitas database ke model domain. Tidak seperti gateway, Repository / DataMapper / DAO menyembunyikan implementasinya. Anda tidak tahu apakah ada PersonGateway di belakang Person. Mungkin, atau mungkin tidak, Anda tidak peduli. Yang Anda tahu adalah harus didukung operasi CRUD untuk setiap objek domain. Ini memisahkan sumber data dan model domain.