DTO (Veri Aktarım Nesneleri) kullanmanın amacı nedir?

DTO'yu kullanmanın amacı nedir ve güncel bir kavram mıdır? POJO'ları görünüm katmanında veri aktarmak ve sürdürmek için kullanıyorum . Bu POJO'lar DTO'lara bir alternatif olarak düşünülebilir mi?

DTO bir kalıptır ve uygulamadan (POJO / POCO) bağımsızdır. DTO, herhangi bir uzak arabirime yapılan her çağrı pahalı olduğu için, her çağrıya verilen yanıtın olabildiğince fazla veri getirmesi gerektiğini söyledi. Bu nedenle, belirli bir görev için veri getirmek için birden fazla istek gerekiyorsa, getirilecek veriler bir DTO'da birleştirilebilir, böylece yalnızca bir istek gerekli tüm verileri getirebilir. Kurumsal Uygulama Mimarisi Desen Kataloğu daha fazla ayrıntıya sahiptir.

DTO'lar eski değil temel bir kavramdır.

Bir kavram olarak DTO (amacı, sunucu tarafından müşteriye iade edilecek verileri toplamak olan nesneler) kesinlikle eski değildir.

Ne olduğunu biraz modası geçmiş hiç mantığı içeren DTOs sahip kavramı olarak kullanılan yalnızca veri iletimi için ve müşteriye iletim önce etki alanı nesnelerden "eşleştirilmiş" ve görüntüleme katmana iletmeden önce modellerini görmek için oraya eşleştirilmiş. Basit uygulamalarda, etki alanı nesneleri genellikle doğrudan DTO'lar olarak yeniden kullanılabilir ve doğrudan görüntüleme katmanına aktarılabilir, böylece yalnızca bir birleşik veri modeli olur. Daha karmaşık uygulamalar için, etki alanı modelinin tamamını istemciye göstermek istemezsiniz, bu nedenle etki alanı modellerinden DTO'lara bir eşleme gereklidir. DTO'lardan verileri çoğaltan ayrı bir görüntü modeline sahip olmak neredeyse hiç mantıklı gelmiyor.

Bununla birlikte, bu fikrin sadece yanlış olmaktan ziyade modası geçmiş olmasının nedeni, bazı (esas olarak eski) çerçevelerin / teknolojilerin bunu gerektirmesidir; çünkü onların etki alanı ve görünüm modelleri POJOS değildir ve bunun yerine doğrudan çerçeveye bağlıdır.

En önemlisi, EJB 3 standardından önceki J2EE'deki Varlık Fasulyeleri POJO'lar değildi ve bunun yerine uygulama sunucusu tarafından oluşturulan proxy nesneleriydi - onları istemciye göndermek mümkün değildi, bu yüzden ayrı bir DTO katmanına sahip olmak konusunda hiçbir seçeneğiniz yoktu. - zorunluydu.

DTO modası geçmiş bir model olmasa da, sıklıkla modası geçmiş görünmesine neden olacak şekilde gereksiz yere uygulanır.

Java Kurumsal topluluğundaki en yanlış kullanılan desen DTO'dur. DTO açıkça bir dağıtım probleminin çözümü olarak tanımlandı. DTO, verileri süreçler arasında verimli bir şekilde ileten kaba taneli bir veri kabı olduğu anlamına geliyordu. ~ Adam Bien

Örneğin, bir JSF ManagedBean’ınız olduğunu varsayalım. Yaygın bir soru, çekirdeğin doğrudan bir JPA Varlığına referans tutması mı yoksa daha sonra bir Varlığa dönüştürülen bazı aracı nesnelere referans göstermesi mi gerektiğidir. DTO olarak adlandırılan bu aracı nesneyi duydum, ancak Yönetilenler ve Varlıklarınız aynı JVM içerisinde çalışıyorsa, DTO düzenini kullanmanın çok faydası olmaz.

Fasulye Doğrulama ek açıklamalarını göz önünde bulundurun. JPA Varlıklarınız muhtemelen @NotNull ve @Size doğrulamaları ile açıklamalıdır. Bir DTO kullanıyorsanız, bu arayüzleri DTO'nuzda tekrarlamak isteyeceksiniz, böylece uzak arayüzünüzü kullanan müşterilerin temel doğrulama işleminde başarısız olduklarını bulmak için bir mesaj göndermeleri gerekmez. DTO'nuz ve Varlığınız arasında Fasulye Doğrulama ek açıklamalarının kopyalanmasıyla ilgili tüm bu çalışmaları düşünün, ancak Görünüm ve Varlıklarınız aynı JVM dahilinde çalışıyorsa, bu fazladan çalışmaya gerek yoktur: sadece Varlıkları kullanın.

IAmTheDude'un Kurumsal Uygulama Mimarisi Modelleri Kataloğu'na bağlantısı DTO'ların kısa bir açıklamasını sunar ve burada aydınlatıcı buldum daha fazla referans var:

• J2EE VE TASARIM MODELLERİ İLE SÖZLEŞME
• DTO'yu JSF + Spring + Hibernate'de kullanma
• Veri Aktarım Nesnelerinin Artıları ve Eksileri

Kesinlikle hayır! Kısa süre önce, kullandığınız iş nesnesinden ziyade DTO'ların daha iyi kullanılması hakkında dersler aldım (muhtemelen ORM haritanıza bağlı).

Ancak, sadece bunları kullanmak için uygun olduklarında kullanın, sadece bunları kullanmak uğruna kullanmayın, çünkü iyi bir kalıp kitapta bahsedilir.
Aklıma gelen tipik bir örnek, 3. taraflara bir çeşit arabirim göstermenizdir. Bu senaryoda, genellikle DTO'larla iyi bir şekilde başarabileceğiniz değiş tokuş edilen nesneleri oldukça sabit tutmak istersiniz.

DTO'ların özellikle faydalı olduğunu düşündüğüm yerlerden biri, API yanıtları için mantık içermesi. Bu şablonla, nesnelerden çeşitli formatlara farklı yanıt türlerini test edilebilir bir şekilde yönetmek kolaydır. Şimdiki rolümde bu kalıbı kullanarak, yığınımız çeşitli müşterilerle (http / mobile) daha izomorfik hale geldiğinden API'lerimiz için yanıt biçimlerini test etmeye başlayabildik. Kesinlikle modası geçmiş değil.