DTO, VO, POJO, JavaBeans arasındaki fark nedir?


Yanıtlar:


848

JavaBeans

JavaBean, Sun tarafından tanımlanan JavaBeans kurallarına uyan bir sınıftır . Wikipedia, JavaBeans'in ne olduğuna dair oldukça iyi bir özete sahiptir :

JavaBeans, Java için bir oluşturucu aracında görsel olarak değiştirilebilen yeniden kullanılabilir yazılım bileşenleridir. Pratik olarak, Java programlama dilinde yazılmış ve belirli bir kurala uyan sınıflardır. Birçok nesneyi tek bir nesneye (fasulye) kapsüllemek için kullanılırlar, böylece birden fazla tekil nesne yerine tek bir fasulye nesnesi olarak geçirilebilirler. JavaBean, serileştirilebilen, boş bir yapıcıya sahip olan ve alıcı ve ayarlayıcı yöntemlerini kullanarak özelliklere erişime izin veren bir Java Nesnesidir.

Bir JavaBean sınıfı olarak işlev görmek için, bir nesne sınıfının yöntem adlandırma, oluşturma ve davranışla ilgili belirli kurallara uyması gerekir. Bu kurallar, JavaBeans'i kullanabilen, yeniden kullanabilen, değiştirebilen ve bağlayabilen araçlara sahip olmayı mümkün kılar.

Gerekli sözleşmeler:

  • Sınıfın genel bir varsayılan yapıcısı olmalıdır. Bu, düzenleme ve etkinleştirme çerçevelerinde kolay örneklemeye olanak tanır.
  • Sınıf özelliklerine, standart bir adlandırma kuralını izleyerek get, set ve diğer yöntemler (erişimci yöntemleri ve mutasyon aracı yöntemleri) kullanılarak erişilebilir olmalıdır. Bu, birçoğu çeşitli özellik türleri için özel editörler içeren, çerçeveler içinde fasulye durumunun kolay otomatik olarak denetlenmesine ve güncellenmesine olanak tanır.
  • Sınıf serileştirilebilir olmalıdır. Bu, uygulamaların ve çerçevelerin, çekirdeğin durumunu VM ve platformdan bağımsız bir şekilde güvenilir bir şekilde kaydetmesini, depolamasını ve geri yüklemesini sağlar.

Bu gereksinimler, arabirimler uygulamak yerine büyük ölçüde kurallar olarak ifade edildiğinden, bazı geliştiriciler JavaBeans'i belirli adlandırma kurallarını izleyen Düz Eski Java Nesneleri olarak görür.

POJO

Düz Eski Java Nesnesi veya POJO, başlangıçta javax.ejb, ağır EJB 2.x'in (özellikle Varlık Fasulyeleri, Vatansız Oturum Fasulyeleri o kadar kötü IMO değildir) aksine, herhangi bir arabirim uygulamayan basit bir hafif Java nesnesini belirtmek için tanıtılan bir terimdir . Bugün, bu terim, fazladan bir şey olmayan herhangi bir basit nesne için kullanılmaktadır. Wikipedia yine POJO'nun tanımlanmasında iyi bir iş çıkarıyor :

POJO, Plain Old Java Object'in kısaltmasıdır. Adı, söz konusu nesnenin özel bir nesne değil, özellikle bir Enterprise JavaBean (özellikle EJB 3'ten önce) değil, sıradan bir Java Nesnesi olduğunu vurgulamak için kullanılır. Terim, Eylül 2000'de Martin Fowler, Rebecca Parsons ve Josh MacKenzie tarafından yapıldı:

"İnsanların sistemlerinde neden normal nesneleri kullanmaya karşı bu kadar karşılandıklarını merak ettik ve bunun basit nesnelerin süslü bir adı olmadığı için olduğu sonucuna vardık. Bu yüzden onlara bir tane verdik ve çok iyi yakalandık."

Bu terim, telefondaki POTS (Düz Eski Telefon Hizmeti) ve C ++ 'da tanımlanan ancak yalnızca C dili özelliklerini kullanan PODS (Düz Eski Veri Yapıları) gibi süslü yeni özellikler kullanmayan teknolojiler için eski terimlerin desenini sürdürmektedir. ve Perl'de POD (Düz Eski Belgeler).

Terim, karmaşık nesne çerçevelerine zıt olan yaygın ve kolay anlaşılır bir terime duyulan ihtiyaç nedeniyle büyük olasılıkla yaygın kabul görmüştür. JavaBean, serileştirilebilen, bağımsız değişken yapıcısı olmayan ve alıcı ve ayarlayıcı yöntemlerini kullanarak özelliklere erişim sağlayan bir POJO'dur. Enterprise JavaBean tek bir sınıf değil, tüm bileşen modelidir (yine EJB 3, Enterprise JavaBeans'in karmaşıklığını azaltır).

POJO'ları kullanan tasarımlar daha yaygın olarak kullanıldıkça, POJO'lara çerçevelerde kullanılan bazı işlevleri ve hangi işlevsellik alanlarının gerçekten gerekli olduğu konusunda daha fazla seçenek sunan sistemler ortaya çıkmıştır. Hazırda Beklet ve İlkbahar örneklerdir.

Değer Nesnesi

Bir Değer Nesnesi veya VO, java.lang.Integerbu tutma değerleri (dolayısıyla değer nesneleri) gibi bir nesnedir . Daha resmi bir tanım için, genellikle Martin Fowler'in Value Object tanımına başvuruyorum :

Kurumsal Uygulama Mimarisi Kalıplarında Değer Nesnesini Para veya tarih aralığı nesnesi gibi küçük bir nesne olarak tanımladım. Temel özellikleri, referans anlambiliminden ziyade değer anlambilimini takip etmeleridir.

Onlara genellikle eşitlik kavramları kimliğe dayalı olmadığı için söyleyebilirsiniz, bunun yerine tüm alanları eşitse iki değer nesnesi eşittir. Tüm alanlar eşit olsa da, bir alt küme benzersizse tüm alanları karşılaştırmanız gerekmez; örneğin, para birimi nesneleri için para birimi kodları eşitliği test etmek için yeterlidir.

Genel bir sezgisel tarama, değer nesnelerinin tamamen değişmez olması gerektiğidir. Bir değer nesnesini değiştirmek istiyorsanız, nesneyi yenisiyle değiştirmelisiniz ve değer nesnesinin değerlerini güncelleştirmesine izin verilmemelidir - güncellenebilir değer nesneleri takma sorunlarına yol açar.

İlk J2EE literatüründe Veri Aktarımı Nesnesi dediğim farklı bir kavramı tanımlamak için değer nesnesi terimi kullanılmıştır . O zamandan beri kullanımlarını değiştirdiler ve bunun yerine Aktarım Nesnesi terimini kullandılar.

Wiki'de ve Dirk Riehle'da değer nesneleri hakkında daha iyi malzemeler bulabilirsiniz .

Veri Aktarım Nesnesi

Veri Aktarım Nesnesi veya DTO, EJB ile tanıtılan (anti) bir kalıptır. Fikir EJB'lerde çok sayıda uzak arama yapmak yerine, ağ üzerinden aktarılabilecek bir değer nesnesindeki verileri kapsüllemekti: bir Veri Aktarım Nesnesi. Wikipedia'nın Veri Aktarım Nesnesi hakkında iyi bir tanımı vardır :

Daha önce değer nesneleri veya VO olarak bilinen veri aktarım nesnesi (DTO), yazılım uygulama alt sistemleri arasında veri aktarımı için kullanılan bir tasarım modelidir. DTO'lar genellikle bir veritabanından veri almak için veri erişim nesneleriyle birlikte kullanılır.

Veri aktarım nesneleri ile iş nesneleri veya veri erişim nesneleri arasındaki fark, bir DTO'nun kendi verilerinin (erişimciler ve mutasyoncular) depolanması ve alınması dışında herhangi bir davranışının olmamasıdır.

Geleneksel bir EJB mimarisinde, DTO'lar iki amaca hizmet eder: ilk olarak, varlık çekirdeklerinin serileştirilememesi sorunu etrafında çalışırlar; ikincisi, görünüm tarafından kullanılacak tüm verilerin denetimi sunum katmanına döndürmeden önce DTO'lara getirildiği ve sıralandığı bir derleme aşamasını dolaylı olarak tanımlarlar.


Yani, birçok insan için DTO'lar ve VO'lar aynı şeydir (ancak Fowler, gördüğümüz gibi başka bir şey ifade etmek için VO'ları kullanır). Çoğu zaman, JavaBeans kurallarına uyarlar ve bu nedenle de JavaBeans'dir. Ve hepsi POJO'lar.


1
Bu yüzden, bunun gibi ilgisiz verileri class SomeClass { public String foo;public String bar; }çok karmaşık mantığa sahip bir sınıf içine aktarmak için oluşturulmuş bir uygunluk sınıfım varsa, bir JavaBean olmadığından emin olun, değiştirilebilir olduğu için bir VO olamaz, DTO? ancak, herhangi bir türden uzaktan çağırma için hedeflenmemiştir. Bir POJO olarak düşünülebilir mi?
Jaime Hablutzel

3
@ user2601512: Hala bir Fasulye olurdu. : P Fasulyenin davranışları olduğu konusunda yanlış bir şey yok - aslında bunun olması bekleniyor. Başka bir şey yapmazsa, temelde bir DTO'dur.
cHao

7
@xSNRG: Kısmen nesneleri diğer kodların üzerinde çalıştığı verilere indirgediği için. Bu, nesnelerin hareket ettikleri ve kendi durumlarından sorumlu olmaları gereken OO perspektifinden geriye doğru bir adımdır. DTO'lar bazen sadece veri aktarıyorsanız - dolayısıyla adı - iyi bir çözümdür, ancak kapsülleme temel olarak pencereden dışarı çıkar ve genellikle gerçek bir nesnenin sağlayabileceği herhangi bir geçerlilik / tutarlılık garantisini kaybedersiniz.
cHao

1
@KumaresanPerumal: İsterseniz yapabilirsiniz. Ancak model, veri katmanından farklıdır ve farklı amaç ve kurallara sahiptir. Veri katmanı tipik olarak düzenlenmiş ve keyfi olarak ayarlanabilen her şeye ihtiyaç duyar ve model ideal olarak verileri gizlemek ve değişmezleri zorlamak ister. Model nesnelerini depolama için kullanmak istiyorsunuz, bir taraftan veya diğer taraftan ödün vermek zorunda kalacaksınız.
cHao

1
@KumaresanPerumal: Veri katmanı, verileri depolamak ve almak için oradadır. Bunu yapmak için, veriyi tutan her hangi nesneye tam erişime ihtiyacı vardır, çünkü geri alma, bir nesnede bir yerde değerlerin ayarlanması anlamına gelir. Ancak model, sistemdeki bu verileri yönetir ve kapsülleme gibi OO ilkelerine bağlıdır - nesnelerin iç durumları üzerinde kontrol sahibi olması ve doğuştan gelenleri keyfi olarak karıştırmak zorunda olmadığı fikri . DTO'lar bu boşluğu doldurabilir; veri katmanı istediği zaman bunlara erişebilir ve model kontrolü ortadan kaldırmak zorunda değildir.
cHao

66

DTO ve VO

DTO - Veri aktarım nesneleri, katmanlar ve katmanlar arasında veri taşımak için kullanılan veri kaplarıdır.

  • Esas olarak öznitelikler içerir. Genel öznitelikleri alıcılar ve ayarlayıcılar olmadan da kullanabilirsiniz.
  • Veri aktarım nesneleri herhangi bir iş mantığı içermez.

Analoji:
Kullanıcı adı, şifre ve e-posta kimliği özelliklerine sahip basit Kayıt formu.

  • Bu form RegistrationServlet dosyasında gönderildiğinde, tüm nitelikleri, görünüm katmanından iş katmanına, nitelikleri java fasulyesine ve sonra DAO'ya veya kalıcılık katmanına geçirdiğinizde alırsınız.
  • DTO'lar, öznitelikleri görünüm katmanından iş katmanına ve son olarak kalıcılık katmanına aktarmaya yardımcı olur.

DTO esas olarak ağ üzerinden verimli bir şekilde veri aktarımı için kullanıldı, JVM'den başka bir JVM'ye bile olabilir.

DTO'lar genellikle java.io.Serializable- JVM üzerinden veri aktarmak için kullanılır.

VO - Bir Değer Nesnesi [1] [2] sabit bir veri kümesini temsil eder ve Java numaralandırmasına benzer. Bir Değer Nesnesinin kimliği, nesne kimliklerinden ziyade durumlarına dayanır ve değişmezdir. Gerçek bir dünya örneği Color.RED, Color.BLUE, SEX.FEMALE vb.

POJO ve JavaBeans Karşılaştırması

[1] Bir POJO'nun Java-Beanness özel özelliklerine, JavaBeans kurallarına uyan genel alıcılar ve ayarlayıcılar aracılığıyla erişilebilmesidir. Örneğin

    private String foo;
    public String getFoo(){...}
    public void setFoo(String foo){...}; 

[2] JavaBeans Serializable uygulamalıdır ve argüman yapıcı olmamalıdır, oysa POJO'da bu kısıtlamalar yoktur.


Yorum sooooo geç için üzgünüm, ama aralarındaki farkları öğreniyorum ve bir sorum var. Ne bir Java Bean sınıf var, ama doSomething () gibi başka bir yöntemle. Ne tür bir sınıf olurdu? Regards
jscherman

@srinivas neden verileri DOMAIN veya MODEL java nesnesine geçiremiyoruz? Ama DTO olmadan MODEL kullanıyorum. lütfen kısaca açıkla. teşekkürler
Kumaresan Perumal

46

Temel olarak,

DTO: "Veri aktarım nesneleri" yazılım mimarisinde ayrı katmanlar arasında seyahat edebilir.

VO: "Değer nesneleri", Tamsayı, Para vb.

POJO: Özel bir nesne olmayan Düz Eski Java Nesnesi.

Java Beans: Java Classserileştirilebilir olması, no-argher alan için bir yapıcı ve bir alıcı ve ayarlayıcıya sahip olmasını gerektirir


Bu açıklamalar çoğunlukla yanlış / eksiktir.
cellepo

24

Java Fasulyeleri EJB'lerle aynı şey değildir.

JavaBeans şartname Java 1.0 Java VB gibi görünüyordu bir IDE manipüle edilecek nesneleri izin Sun'ın girişimiydi. "Java Beans" olarak nitelendirilen nesneler için kurallar koyuldu:

  1. Varsayılan kurucu
  2. Özel adlandırma kuralını izleyen özel veri üyeleri için mektuplar ve ayarlayıcılar
  3. Serileştirilebilir
  4. Belki de unuttuğum diğerleri.

EJB'ler daha sonra geldi. Dağıtılmış bileşenleri ve işlemsel bir modeli birleştirerek, iş parçacıklarını, havuzu, yaşam döngüsünü yöneten ve hizmetler sağlayan bir kapta çalışırlar. Java Fasulyeleri'nden çok uzaklar.

DTO'lar Java bağlamında ortaya çıktı, çünkü insanlar EJB 1.0 spesifikasyonunun veritabanıyla çok "konuşkan" olduğunu keşfettiler. Her veri öğesi için bir gidiş dönüş yapmak yerine, insanlar bunları Java Fasulyesi'ne toplu olarak paketleyip etrafına gönderirdi.

POJO'lar EJB'lere karşı bir reaksiyondu.


1
Yanılmışım ve mesajımı silmeyi tercih ettim. Düzeltme için teşekkürler. POJO anlamının bir süre önce değiştiğini fark etmek istiyorum. İlk olarak, sadece özel mülklerden ve erişimcilerinden yapılırlar. Şimdi, bir
POJO'yu

Sorunun sorduğu gibi VO hakkında ne söylenebilir? Bu, tüm soruya cevap verene kadar bir cevap değildir
cellepo

4

POJO : Başka bir java dosyasını (sınıfı) genişletmeyen veya uygulamayan bir java dosyasıdır (sınıf).

Bean : Tüm değişkenlerin özel, yöntemlerin ortak olduğu ve değişkenlere erişmek için uygun alıcılar ve ayarlayıcıların kullanıldığı bir java dosyasıdır (sınıf).

Normal sınıf : Genel / özel / varsayılan / korumalı değişkenlerden oluşabilen ve başka bir java dosyasını (sınıf) genişletebilen veya uygulayamayan bir java dosyasıdır (sınıf).


Sorunun sorduğu gibi VO hakkında ne söylenebilir? Bu, tüm soruya cevap verene kadar bir cevap değildir
cellepo

1

Hakkında İlk Konuşma

Normal Sınıf - bu, herhangi bir sınıfın normalde java'da tanımlandığı anlamına gelir, farklı yöntem özellikleri vb.
Oluşturduğunuz anlamına gelir . .

ve ondan sonra son POJO hakkında

POJO - POJO , herhangi bir hizmeti olmayan sınıfın yalnızca varsayılan bir yapıcı ve özel özelliğe sahip olması ve bu değere karşılık gelen ayarlayıcı ve alıcı yöntemlerini ayarlama özelliğidir. Düz Java Nesnesinin kısa biçimidir.


Sorunun sorduğu gibi VO hakkında ne söylenebilir? Bu, tüm soruya cevap verene kadar bir cevap değildir
cellepo

1
  • Değer Nesnesi : Nesnelerin değerine göre nesnelerin eşitliğini ölçmeniz gerektiğinde kullanın.
  • Veri Aktarım Nesnesi : Uzak sunucuya birden fazla çağrı yapılmasını önlemek için, istemciden sunucuya tek seferde birden fazla niteliği olan verileri aktarın .
  • Düz Eski Java Nesnesi : Basit bir sınıf gibi hangi özellikleri, genel no-arg yapıcısı. JPA varlığı için beyan ettiğimiz gibi.

Fark-arası değer-nesne-desen ve veri transfer model

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.