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


133

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.

Jawaban:


96

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).


15
Sebenarnya tidak ada perbedaan besar antara DAO dan TableDataGateway dan di [Fowler, PoEAA] [1] mereka mengatakan dengan tepat bahwa: "[Alur et al.] [2] membahas pola Objek Akses Data, yang merupakan Table Data Gateway. .. Saya telah menggunakan nama yang berbeda, sebagian karena saya melihat pola ini sebagai penggunaan khusus dari konsep Gateway (466) yang lebih umum dan saya ingin nama pola mencerminkannya. " [1]: martinfowler.com/books/eaa.html [2]: books.google.pt/books/about/…
Miguel Gamboa

9
Poin yang bagus. Kesan saya adalah bahwa PoEAA memberikan definisi TableDataGateway lebih sempit daripada DataAccessObject. Yang pertama tampaknya menyiratkan pemetaan satu ke satu dengan tabel database (relasional), di mana DAO dapat bertindak sebagai Fasad untuk berbagai sumber daya non-relasional yang mendasarinya. Penekanan dalam DAO adalah kemampuan untuk mengganti datastore yang mendasarinya, penekanan pada TableDataGateway adalah enkapsulasi operasi SQL pada satu tabel (tidak harus dalam mode netral / portabel datastore).
Pierce Hickey

31

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.


4
@MladenMihajlovic, hanya karena Anda tidak mengerti atau setuju, tidak berarti jawaban ini tidak valid atau acara tidak benar.
Cypher

2
@MladenMihajlovic bukan itu yang dikatakan jawaban ini. Kalimat terakhir merangkumnya.
Cypher

2
@Cypher Apakah sebagian besar pola ini sama? Tidak, mereka bukan. Implementasi pola gateway berbeda dari implementasi pola repositori. Mereka mungkin terlihat sama dengan mata yang tidak terlatih, tetapi sebenarnya tidak. Juga, seperti yang ditunjukkan Mladen Mihajlovic dengan benar, Jawaban ini sangat salah. Logika bisnis dan lapisan layanan adalah dua hal yang berbeda.
Frederik Krautwald

1
@ Chypher Ini bukan masalah pendapat, tapi fakta. Pola Gateway dirumuskan oleh Martin Fowler dalam PoEAA-nya, dan sebagian besar terkait dengan pola Facade atau Adapter [GoF]. Perbedaannya adalah bahwa Gateway ditulis untuk penggunaan tertentu dan biasanya tidak ada antarmuka yang ada. Gateway, biasanya, hanya melibatkan dua objek, dan sumber daya yang dibungkus tidak memiliki pengetahuan tentang Gateway. (lanjutan ...)
Frederik Krautwald

3
Ini lebih merupakan komentar daripada jawaban.
Pétur Ingi Egilsson

31

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

  • Pemeta Data akan menerima objek Model Domain (Entitas) sebagai param dan akan menggunakannya untuk mengimplementasikan operasi CRUD
  • Table Data Gateway akan menerima semua params (sebagai primitif) untuk metode dan tidak akan tahu apa-apa tentang objek Model Domain (Entitas).

    Pada akhirnya keduanya akan bertindak sebagai mediator antara objek dalam memori dan database.


  • 6
    tautan sudah basi
    imel96


    15

    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.


    1

    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.

    Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
    Licensed under cc by-sa 3.0 with attribution required.