Veri Eşleştiricisi, Tablo Veri Ağ Geçidi (Ağ Geçidi), Veri Erişim Nesnesi (DAO) ve Depo modelleri arasındaki fark nedir?


133

Tasarım kalıbı becerilerimi tazelemeye çalışıyorum ve bu kalıplar arasındaki farkların ne olduğunu merak ediyorum. Hepsi aynı şey gibi görünüyor - belirli bir varlık için veritabanı mantığını kapsülleyin, böylece çağıran kodun temeldeki kalıcılık katmanı hakkında bilgisi olmaz. Kısa araştırmamdan, hepsi tipik olarak standart CRUD yöntemlerinizi uygular ve veritabanına özgü ayrıntıları soyutlar.

Adlandırma kurallarından ayrı olarak (örn. CustomerMapper, CustomerDAO, CustomerGateway, CustomerRepository), eğer varsa, fark nedir? Bir fark varsa, birini diğerine ne zaman seçerdiniz?

Geçmişte aşağıdakine benzer bir kod yazardım (basitleştirilmiş, doğal olarak - normalde genel mülkleri kullanmazdım):

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);
}

ve CustomerGatewaytüm yöntemler için belirli veritabanı mantığını uygulayan bir sınıfa sahip olun. Bazen bir arabirim kullanmaz ve CustomerGateway'deki tüm yöntemleri statik hale getiririm (biliyorum, biliyorum, bu onu daha az test edilebilir kılar), böylece şöyle diyebilirim:

Customer cust = CustomerGateway.GetCustomerByID(42);

Bu, Veri Eşleştiricisi ve Depo modelleri için aynı ilke gibi görünmektedir; DAO kalıbı (ki sanırım Ağ Geçidi ile aynı şey mi?) veritabanına özgü ağ geçitlerini teşvik ediyor gibi görünüyor.

Bir şey mi kaçırıyorum? Aynı şeyi yapmanın 3-4 farklı yoluna sahip olmak biraz garip görünüyor.

Yanıtlar:


97

Örnek terimleriniz; DataMapper, DAO, DataTableGateway ve Repository, hepsinin benzer bir amacı vardır (birini kullandığımda, bir Müşteri nesnesini geri almayı umuyorum), ancak farklı amaç / anlam ve sonuçta ortaya çıkan uygulama.

Bir Depo "daha ayrıntılı sorgulama yeteneği dışında bir koleksiyon gibi davranır" [ Evans, Etki Alanına Dayalı Tasarım ] ve bir "bellek cephesindeki nesneler" olarak düşünülebilir ( Depo tartışması )

Bir DataMapper, "verileri nesneler ve veritabanı arasında hareket ettirirken aynı zamanda onları birbirinden ve eşleyicinin kendisinden bağımsız tutar" ( Fowler, PoEAA, Mapper )

Bir TableDataGateway , "bir veritabanı tablosuna bir Ağ geçididir (harici bir sisteme veya kaynağa erişimi kapsülleyen nesne). Bir örnek tablodaki tüm satırları yönetir " ( Fowler, PoEAA, TableDataGateway )

Bir DAO "bir veri kaynağının istemci arayüzünü veri erişim mekanizmalarından ayırır / belirli bir veri kaynağının erişim API'sini genel bir istemci arayüzüne uyarlar " veri erişim mekanizmalarının verileri kullanan koddan bağımsız olarak değişmesine izin verir " ( Sun Blueprints )

Depo, veritabanı etkileşimi kavramını açığa çıkarmayan çok genel görünmektedir. Bir DAO, farklı temel veritabanı uygulamalarının kullanılmasını sağlayan bir arabirim sağlar. Bir TableDataGateway, özellikle tek bir tablonun etrafındaki ince bir sarmalayıcıdır. Bir DataMapper, Model nesnesinin veritabanı gösteriminden bağımsız olarak (zaman içinde) gelişmesini sağlayan bir aracı görevi görür.


15
Gerçekte DAO ile TableDataGateway arasında büyük bir fark yoktur ve [Fowler, PoEAA] [1] 'da tam olarak şunu söylüyorlar: "[Alur ve diğerleri] [2] bir Tablo Veri Ağ Geçidi olan Veri Erişim Nesnesi modelini tartışıyor. .. Farklı bir isim kullandım, çünkü kısmen bu modeli daha genel Gateway (466) konseptinin belirli bir kullanımı olarak görüyorum ve model isminin bunu yansıtmasını istiyorum. " [1]: martinfowler.com/books/eaa.html [2]: books.google.pt/books/about/…
Miguel Gamboa

9
İyi bir nokta. Benim izlenimim, PoEAA tarafından sağlanan TableDataGateway tanımının DataAccessObject'ten daha dar olduğu yönünde. İlki, bir (ilişkisel) veritabanı tablosu ile bire bir eşlemeyi ima ediyor gibi görünmektedir; burada bir DAO, birden fazla temeldeki ilişkisel olmayan kaynak için bir Cephe görevi görebilir. Bir DAO'daki vurgu, temeldeki veri deposunun yerini alma yeteneğidir, TableDataGateway'deki vurgu, SQL işlemlerinin tek bir tablo üzerinde kapsüllenmesidir (mutlaka bir veri deposu nötr / taşınabilir şekilde olması gerekmez).
Pierce Hickey

31

Yazılım tasarım dünyasında (en azından öyle hissediyorum) iyi bilinen eski şeyler ve kalıplar için yeni isimler icat etme eğilimi var. Ve yeni bir paradigmaya sahip olduğumuzda (belki de zaten var olan şeylerden biraz farklıdır), genellikle her kademe için bir dizi yeni isimle birlikte gelir. Yani "İş Mantığı", sadece SOA yaptığımızı söylediğimiz için "Hizmet Katmanı" olur ve DAO, sırf DDD yaptığımızı söylediğimiz için Depo olur (ve bunların her biri aslında yeni ve benzersiz bir şey değildir, ama yine: yeni isimler zaten bilinen kavramlar için aynı kitapta toplanmıştır). Bu yüzden, tüm bu modern paradigmalar ve kısaltmaların TAMAMEN aynı anlama geldiğini söylemiyorum, ama bu konuda gerçekten çok paranoyak olmamalısınız. Çoğunlukla bunlar, farklı ailelerden gelen aynı kalıplardır.


4
@MladenMihajlovic, anlamamanız veya katılmamanız, bu cevabın geçerli olmadığı veya olayın doğru olmadığı anlamına gelmez.
Cypher

2
@MladenMihajlovic, bu cevabın söylediği bu değil. Son cümle bunu özetliyor.
Cypher

2
@Cypher Bu desenler çoğunlukla aynı mı? Hayır değiller. Ağ geçidi modelinin uygulanması, depo modelinin uygulanmasından farklıdır. Eğitimsiz gözlere aynı görünebilirler, ama değiller. Ayrıca, Mladen Mihajlovic'in doğru bir şekilde işaret ettiği gibi, Bu cevap oldukça yanlış. İş mantığı ve hizmet katmanı iki farklı şeydir.
Frederik Krautwald

1
@Cypher Gerçekten bir fikir meselesi değil, gerçekler. Ağ Geçidi modeli, PoEAA'sında Martin Fowler tarafından formüle edilmiştir ve çoğunlukla Cephe veya Adaptör modelleriyle [GoF] ilgilidir. Farklılıklar, Ağ Geçidinin belirli bir kullanım için yazılmış olması ve genellikle mevcut bir arayüz olmamasıdır. Ağ Geçidi, genellikle yalnızca iki nesne içerir ve sarılmakta olan kaynak Ağ Geçidi hakkında bilgi sahibi değildir. (devam ediyor ...)
Frederik Krautwald

3
Bu bir cevaptan çok bir yorumdur.
Pétur Ingi Egilsson

31

Veri Eşleştiricisi vs Tablo Veri Ağ Geçidi Uzun lafın kısası:

  • Veri Eşleştiricisi, Etki Alanı Modeli nesnesini (Varlık) param olarak alacak ve CRUD işlemlerini uygulamak için kullanacaktır
  • Tablo Veri Ağ Geçidi, yöntemler için tüm parametreleri (ilkel olarak) alır ve Etki Alanı Modeli nesnesi (Varlık) hakkında hiçbir şey bilmeyecektir.

    Sonunda her ikisi de bellek içi nesneler ve veritabanı arasında aracı görevi görecek.


  • 6
    bağlantı bayat oldu
    imel96


    15

    İyi bir noktaya temas ettiniz. En aşina olduğunuz birini seçin. Açıklığa kavuşturmaya yardımcı olabilecek birkaç şeye dikkat çekmeyi seviyorum.

    Tablo Veri Ağ Geçidi, esas olarak tek bir tablo veya görünüm için kullanılır. Tüm seçimleri, eklemeleri, güncellemeleri ve silmeleri içerir. Yani Müşteri, sizin durumunuzda bir tablo veya bir görünümdür. Dolayısıyla, tablo veri ağ geçidi nesnesinin bir örneği tablodaki tüm satırları işler. Genellikle bu, veritabanı tablosu başına bir nesne ile ilgilidir.

    Veri Eşleştiricisi herhangi bir alan mantığından daha bağımsız ve daha az bağlı olsa da (eşleşme olduğuna ya da olmadığına inanıyorum). Nesneler ve veritabanı arasında verileri aktarırken, bunları birbirinden ve eşleyicinin kendisinden bağımsız tutmak yalnızca bir ara katmandır.

    Dolayısıyla, tipik olarak bir eşleyicide, ekleme, güncelleme, silme gibi yöntemleri görürsünüz ve tablo veri ağ geçidinde getcustomerbyId, getcustomerbyName, vb. Bulursunuz.

    Veri aktarım nesnesi yukarıdaki iki modelden farklıdır, çünkü esas olarak bir dağıtım modeli ve yukarıdaki iki modelde olduğu gibi bir veri kaynağı modeli değildir. Esas olarak uzak arabirimle çalışırken ve her arama pahalı olabileceğinden aramalarınızı daha az konuşkan hale getirmeniz gerektiğinde kullanın. Bu nedenle, genellikle daha fazla iş kuralları veya işleme için tüm verileri sunucuya geri taşıyabilen kablo üzerinden serileştirilebilen bir DTO tasarlayın.

    Şimdiye kadar kullanma şansım olmadığından, ancak başkalarının cevaplarına bakacağımdan, depo modelinde çok bilgili değilim.


    1

    Aşağıda sadece benim anlayışım.

    TableGateWay / RowDataGateWay : Bu bağlamda, Ağ Geçidi, her "etki alanı nesnesi ağ geçidi" ile her "etki alanı nesnesi" eşlemesine sahip belirli bir uygulamaya atıfta bulunur. Örneğin, Kişimiz varsa, Kişi etki alanı nesnesini veritabanına depolamak için bir PersonGateway'e sahip olacağız . Kişi, Çalışan, Müşteri vb. Varsa, PersonGateway, EmployeeGateway ve CustomerGateway'e sahip olacağız. Her ağ geçidinin o nesne için belirli CRUD işlevi olacaktır ve diğer ağ geçidiyle hiçbir ilgisi yoktur. Burada yeniden kullanılabilir kod / modül yoktur. Ağ geçidi ayrıca RowDataGateway veya TableGateway olarak bölünebilir, bir "id" veya "nesne" iletmenize bağlı olarak değişir. Ağ geçidi genellikle Aktif kayıt ile karşılaştırılır. Etki alanı modelinizi veritabanı şemasına bağlar.

    Depo / DataMapper / DAO : Aynı şey. Hepsi, veritabanı varlıklarını etki alanı modeline aktaran Persistence katmanına atıfta bulunur. Ağ geçidinin aksine, Depo / Veri Eşleyici / DAO, uygulamayı gizler. Person'un arkasında bir PersonGateway olup olmadığını bilmiyorsunuz. Olabilir veya olmayabilir, umursamıyorsun. Tek bildiğiniz, her etki alanı nesnesi için desteklenen CRUD işlemlerine sahip olması gerektiğidir. Veri kaynağı ile alan modelini birbirinden ayırır.

    Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
    Licensed under cc by-sa 3.0 with attribution required.