Yanıtlar:
DAOveri kalıcılığının bir soyutlamasıdır .
Repositorybir nesne koleksiyonunun soyutlamasıdır .
DAOveritabanına daha yakın, genellikle tablo merkezli olarak değerlendirilir.
Repositoryyalnızca Toplu Köklerde işlem yapan Alan Adına daha yakın kabul edilir.
RepositoryDAO's kullanılarak uygulanabilir , ancak tam tersini yapmazsınız.
Ayrıca, a Repositorygenellikle daha dar bir arayüzdür. Bu bir ile, sadece nesneleri topluluğudur olmalıdır Get(id), Find(ISpecification), Add(Entity).
Gibi bir yöntem Updatebir uygun olduğunu DAO, ancak bir değil Repository- bir kullanırken Repository, kuruluşlara değişiklikler genellikle ayrı UnitOfWork tarafından izlenir.
RepositoryGerçekten daha çok olan a olarak adlandırılan uygulamaları görmek yaygın görünmektedir DAOve bu nedenle aralarındaki fark hakkında bazı karışıklıklar olduğunu düşünüyorum.
Tamam, yorumlara ne koyduğumu daha iyi açıklayabileceğimi düşünüyorum :). Yani, DAO, Depo'dan daha esnek bir model olsa da, temel olarak, her ikisini de aynı şekilde görebilirsiniz. Her ikisini de kullanmak isterseniz DAO'larınızdaki Depoyu kullanırsınız. Her birini aşağıda açıklayacağım:
Belirli bir nesne türünün deposu - belirli bir nesne türünü aramanıza ve saklamanıza olanak tanır. Genellikle SADECE bir tür nesneyi işler. Örneğin AppleRepository, yapmanıza izin verir AppleRepository.findAll(criteria)veya AppleRepository.save(juicyApple). Deponun Etki Alanı Modeli terimlerini kullandığını unutmayın (DB terimleri değil - verinin her yerde nasıl devam ettiği ile ilgili hiçbir şey yoktur).
Bir veri havuzu büyük olasılıkla tüm verileri aynı tabloda depolayacaktır, ancak kalıp bunu gerektirmez. Yine de yalnızca bir tür veri işleyebilmesi gerçeği, mantıksal olarak bir ana tabloya bağlanır (DB kalıcılığı için kullanılıyorsa).
DAO, verileri sizin için bulan bir sınıftır (çoğunlukla bir bulucudur, ancak genellikle verileri depolamak için de kullanılır). Kalıp, aynı türdeki verileri depolamanızı kısıtlamaz, böylece ilgili nesneleri bulan / depolayan bir DAO'ya kolayca sahip olabilirsiniz.
Kolayca gibi yöntemleri ortaya Userdao sahip olabilir
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)Bunların tümü Kullanıcı (ve güvenlik) ile ilgilidir ve aynı DAO altında belirtilebilir. Depo için durum böyle değil.
Her iki örüntünün gerçekten aynı anlama geldiğini (verileri sakladıklarını ve buna erişimi soyutladıklarını ve her ikisinin de etki alanı modeline daha yakın ifade edildiğini ve neredeyse hiç DB referansı içermediğini) unutmayın, ancak kullanım şekilleri biraz farklı olabilir, DAO biraz daha esnek / genel olurken, Depo yalnızca bir tür için biraz daha spesifik ve kısıtlayıcıdır.
CarDescription, örneğin language_idyabancı anahtar gibi bir şeyim var - o zaman böyle bir şey yapmam gerektiğini almak için: CarRepository.getAll(new Criteria(carOwner.id, language.id));bu bana belirli bir dilde bir dilin tüm arabalarını verecek - bunu yapmanın doğru yolu ?
CarRepository.findByLanguageId(language.id)ve kodu yazmanız bile gerekmez, sadece bu adla bir yöntemle arayüzü tanımlarsınız ve Spring Data sizin için varsayılan sınıf uygulamasını oluşturmaya özen gösterir. Oldukça temiz şeyler;)
findById). Ve pratikte bitti. Daha sonra Spring Data'nın yaptığı şey, oluşturduğunuz tüm bu arayüzleri Depo arayüzünü genişleten ve sınıfları sizin için yaratan şeydir. Bu sınıfları asla göremezsiniz ve yeni örnekler oluşturamazsınız, ancak yalnızca arayüzü otomatik olarak bağlayabileceğiniz ve Spring'in bu depo nesnesini bulmasına izin verebileceğiniz için gerekmez.
DAO ve Havuz kalıbı, Veri Erişim Katmanı'nı (DAL) uygulamanın yoludur. Önce DAL ile başlayalım.
Veritabanına erişen nesne yönelimli uygulamaların, veritabanı erişimini işlemek için bir mantığı olmalıdır. Kodu temiz ve modüler tutmak için veritabanı erişim mantığının ayrı bir modüle ayrılması tavsiye edilir. Katmanlı mimaride bu modül DAL'dir.
Şimdiye kadar, belirli bir uygulamadan bahsetmedik: veritabanı erişim mantığını ayrı bir modüle yerleştiren sadece genel bir prensip.
Şimdi, bu prensibi nasıl uygulayabiliriz? Bunu, özellikle Hibernate gibi çerçevelerle uygulamanın bir yolu DAO modelidir.
DAO modeli, tipik olarak her etki alanı varlığının kendi DAO'suna sahip olduğu DAL oluşturmanın bir yoludur. Örneğin, Userve UserDao, Appointmentve AppointmentDao: vs ile hazırda DAO bir örnek, http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .
O zaman Depo deseni nedir? DAO gibi, Depo deseni de DAL'ye ulaşmanın bir yoludur. Havuz modelindeki ana nokta, istemci / kullanıcı perspektifinden bir koleksiyon olarak görünmesi veya davranmasıdır. Bir koleksiyon gibi davranmakla kastedilen, onun gibi somutlaştırılması gerektiği değildir Collection collection = new SomeCollection(). Bunun yerine, ekleme, kaldırma, içerir, vb. İşlemleri desteklemesi gerektiği anlamına gelir. Bu, Havuz modelinin özüdür.
Uygulamada, örneğin Hazırda Bekletme modunun kullanılması durumunda, DAO ile Havuz kalıbı gerçekleştirilir. Bu bir DAL örneğidir, aynı anda hem DAO kalıbı hem de Depo kalıbı örneği olabilir.
Havuz kalıbı DAO'nun üzerine inşa edilen bir şey olmak zorunda değildir (bazılarının önerebileceği gibi). DAO'lar yukarıda belirtilen işlemleri destekleyen bir arabirim ile tasarlandıysa, Depo modelinin bir örneğidir. Bir düşünün, DAO'lar zaten koleksiyona benzer bir dizi işlem sağlıyorsa, bunun üzerine fazladan bir katmana ne gerek var?
Açıkçası, bu teknik bir ayrım değil, anlamsal bir ayrım gibi görünüyor. Veri Erişim Nesnesi ifadesi "veritabanına" hiç değinmez. Ve veritabanına dayalı olacak şekilde tasarlayabilseniz de, çoğu insanın tasarım hatası yapmayı düşüneceğini düşünüyorum.
DAO'nun amacı, veri erişim mekanizmasının uygulama ayrıntılarını gizlemektir. Havuz kalıbı nasıl farklı? Anlayabildiğim kadarıyla değil. Bir Havuz söylemek bir DAO'dan farklıdır çünkü bir nesne koleksiyonu ile uğraşıyorsunuz / geri dönüyorsanız doğru olamaz; DAO'lar ayrıca nesne koleksiyonlarını döndürebilir.
Havuz kalıbı hakkında okuduğum her şey bu ayrıma dayanıyor: kötü DAO tasarımı vs iyi DAO tasarımı (diğer adıyla depo tasarım deseni).
Depo, Etki Alanına Dayalı Tasarımın bir parçası olan daha soyut etki alanına yönelik bir terimdir, etki alanı tasarımınızın ve ortak bir dilin bir parçasıdır, DAO veri erişim teknolojisi için teknik bir soyutlamadır, veri havuzu yalnızca mevcut verilerin ve fabrikaların oluşturulması için yönetilmesiyle ilgilidir veri.
bu bağlantıları kontrol edin:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
Temel fark, bir havuzun bir toplamda toplam köklere erişimi, DAO ise varlıklara erişimi yönetmesidir. Bu nedenle, bir havuzun toplam köklerin gerçek kalıcılığını bir DAO'ya devretmesi yaygındır. Ayrıca, toplam kök diğer varlıkların erişimini işlemesi gerektiğinden, bu erişimi diğer DAO'lara devretmesi gerekebilir.
DAO, veritabanı / veri dosyaları veya başka bir kalıcılık mekanizması üzerinde soyutlama sağlar, böylece kalıcılık katmanı uygulama ayrıntılarını bilmeden manipüle edilebilir.
Depo sınıflarında ise, "uygulama perspektifinden" bir işlem yapmak için tek bir Depo yönteminde birden çok DAO sınıfı kullanılabilir. Bu nedenle, Etki Alanı katmanında birden çok DAO kullanmak yerine, işlemi gerçekleştirmek için havuzu kullanın. Depo, aşağıdakiler gibi bazı uygulama mantığı içerebilen bir katman : Bellek içi önbellekte veri varsa, önbellekten alın, aksi takdirde ağdan veri alın ve bir dahaki sefere almak için bellek içi önbellekte saklayın.
Depo, iyi tasarlanmış DAO'dan başka bir şey değildir.
ORM tablo merkezli ancak DAO değil.
Depoda birkaç DAO kullanmaya gerek yoktur, çünkü DAO'nun kendisi bir aracın nerede ve nasıl ısrar ederse sürsün ORM depoları / varlıkları veya herhangi bir DAL sağlayıcısı ile tam olarak aynı şeyi yapabilir 1 tablo, 2 tablo, n tablo, yarım masa, a web servisi, tablo ve web servisi vb. Hizmetler çeşitli DAO / depolar kullanır.
Kendi DAO'm, diyelim ki Cardao sadece Araba DTO ile ilgileniyor, yani, sadece Araba DTO'yu girişe alın ve sadece araba DTO veya araba DTO koleksiyonlarını iade edin.
Tıpkı Depo gibi, DAO aslında iş mantığı için sebat arayüzlerinin sebat stratejileri veya mirasları tarafından korkutulmamasına izin veren bir IoC'dir. DAO hem kalıcılık stratejisini kapsüllemekte hem de domaine ile ilgili kalıcılık arayüzünü sunmaktadır. Depo, iyi tanımlanmış bir DAO'nun gerçekte ne olduğunu anlamayanlar için başka bir kelimedir.
DAO'nun veya Havuz kalıbının aşağıdaki durum için en uygun olup olmadığını bulmaya çalışın: RDBMS, LDAP, OODB, XML depoları ve düz dosyalar.
İlgileniyorsanız aşağıdaki bağlantılara da bakın:
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
çok basit bir cümle: DAO'lar veritabanına daha yakınken, genellikle çok daha tablo merkezli olmak üzere, Depoların koleksiyonları temsil etmesidir.
Bahar çerçevesinde, depo adı verilen bir ek açıklama vardır ve bu ek açıklamanın açıklamasında, bu tartışma için yararlı olduğunu düşündüğüm depo hakkında yararlı bilgiler vardır.
Açıklamalı bir sınıfın, başlangıçta Etki Alanına Dayalı Tasarım (Evans, 2003) tarafından "bir nesne koleksiyonunu taklit eden depolama, geri alma ve arama davranışını kapsüllemek için bir mekanizma" olarak tanımlanan bir "Havuz" olduğunu belirtir.
"Veri Erişim Nesnesi" gibi geleneksel Java EE kalıpları uygulayan ekipler de bu klişeyi DAO sınıflarına uygulayabilirler, ancak bunu yapmadan önce Veri Erişim Nesnesi ile DDD stili depolar arasındaki ayrımı anlamak için özen gösterilmelidir. Bu açıklama genel amaçlı bir stereotiptir ve bireysel ekipler anlambilimlerini daraltabilir ve uygun şekilde kullanabilirler.
Bu şekilde açıklamalı bir sınıf, bir PersistenceExceptionTranslationPostProcessor ile birlikte kullanıldığında Spring DataAccessException çevirisi için uygundur. Ek açıklamalı sınıf ayrıca takımlama, yönler, vb. Amaçlarıyla genel uygulama mimarisindeki rolü konusunda açıklığa kavuşturulmuştur.
IRepositoryarayüzünüzü tam anlamıyla uygulamasını istemezsiniz . Deponuzun DAO'ları uygulamasında kullanmasını istersiniz. Unutmayın, bir DAO tablo başına bir nesne olacaktır, ancak bir Havuz neredeyse her zaman tek bir Varlık oluşturmak için birden fazla DAO kullanmalıdır. Durum böyle değilse, Deponuz ve Varlığınızın yalnızca tek bir tabloya erişmesi gerektiğini düşünüyorsanız, büyük olasılıkla bir anemik etki alanı oluşturuyorsunuzdur.