Veri Aktarım Nesnesi nedir?

Veri Aktarım Nesnesi nedir?

MVC'de model sınıfları DTO'dur ve eğer değilse farklılıklar nedir ve ikisine de ihtiyacımız var mı?

Veri Aktarım Nesnesi, verileri kapsüllemek ve bir uygulamanın bir alt sisteminden diğerine göndermek için kullanılan bir nesnedir.

DTO'lar, kendisi ve kullanıcı arayüzü katmanı arasında veri aktarmak için bir N-Katman uygulamasında Hizmetler katmanı tarafından en yaygın olarak kullanılır. Buradaki en önemli fayda, dağıtılmış uygulamalarda kablo üzerinden gönderilmesi gereken veri miktarını azaltmasıdır. Ayrıca MVC modelinde harika modeller yaparlar.

DTO'lar için başka bir kullanım, yöntem çağrıları için parametreleri kapsüllemek olabilir. Bir yöntem 4 veya 5'ten fazla parametre alıyorsa bu yararlı olabilir.

DTO desenini kullanırken, DTO montajcılarını da kullanabilirsiniz. Birleştiriciler Etki Alanı Nesnelerinden DTO'lar oluşturmak için kullanılır veya bunun tersi de geçerlidir.

Etki Alanı Nesnesinden DTO'ya ve tekrar geri dönüştürme maliyetli bir süreç olabilir. Dağıtılmış bir uygulama oluşturmuyorsanız, Martin Fowler'ın burada açıkladığı gibi, muhtemelen desenden büyük faydalar görmeyeceksiniz.

DTO'nin tanımı Martin Fowler'in sitesinde bulunabilir . DTO'lar parametreleri yöntemlere ve dönüş tipleri olarak aktarmak için kullanılır. Birçok kişi kullanıcı arayüzünde bulunanları kullanıyor, ancak diğerleri alan adlarını onlardan şişiriyor.

Bir DTO aptal bir nesnedir - sadece özellikleri tutar ve alıcıları ve ayarlayıcıları vardır, ancak herhangi bir öneme sahip başka bir mantığı yoktur (belki bir karşılaştırma () veya eşittir () uygulaması dışında).

Tipik olarak MVC'deki model sınıfları (burada .net MVC olduğu varsayılarak) DTO'lar veya DTO'ların koleksiyonları / toplamalarıdır

Genel olarak Değer Nesneleri Değişmez olmalıdır. Gibi Tamsayı veya dize Java nesneleri. Bunları yazılım katmanları arasında veri aktarımı için kullanabiliriz. Yazılım, mikro hizmet ortamında veya eski bir Java Enterprise Uygulamasında olduğu gibi farklı uzak düğümlerde çalışan katmanlar veya hizmetler içeriyorsa. İki sınıfın neredeyse kesin kopyalarını almalıyız. Burası DTO'larla tanıştığımız yer.

|-----------|                                                   |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------|                                                   |--------------|

Eski Java Enterprise Systems'da DTO'lar içinde çeşitli EJB öğeleri bulunabilir.

Bunun en iyi uygulama olduğunu bilmiyorum ya da değil ama şahsen benim gibi MVC / Boot Projelerimde Değer Nesneleri kullanın :

        |------------|         |------------------|                             |------------|
-> Form |            | -> Form |                  | -> Entity                   |            |
        | Controller |         | Service / Facade |                             | Repository |
<- View |            | <- View |                  | <- Entity / Projection View |            |
        |------------|         |------------------|                             |------------|

Denetleyici katmanı varlıkların ne olduğunu bilmiyor. Form ve Görünüm Değer Nesneleri ile iletişim kurar . Form Nesneleri JSR 303 Doğrulama ek açıklamalarına sahiptir (örneğin @NotNull) ve Görünüm Değeri Nesneleri özel serileştirme için Jackson Ek Açıklamalarına sahiptir. (örneğin @JsonIgnore)

Hizmet katmanı, Varlık Nesneleri'ni kullanarak havuz katmanıyla iletişim kurar. Varlık nesneleri üzerinde JPA / Hazırda Bekletme / Bahar Verisi ek açıklamaları bulunur. Her katman yalnızca alt katmanla iletişim kurar. Katmanlar arası iletişim, dairesel / döngüsel bağımlılık nedeniyle yasaktır.

User Service ----> XX CANNOT CALL XX ----> Order Service

Bazı ORM Çerçeveleri ek arabirimler veya sınıflar kullanarak projeksiyon yapabilir. Böylece havuzlar View nesnelerini doğrudan döndürebilir. Orada sizin için ek bir dönüşüme ihtiyacınız yok.

Örneğin bu Kullanıcı varlığımız:

@Entity
public final class User {
    private String id;
    private String firstname;
    private String lastname;
    private String phone;
    private String fax;
    private String address;
    // Accessors ...
}

Ancak, yalnızca id, ad, soyadı içeren Sayfalandırılmış bir kullanıcı listesi döndürmelisiniz. Ardından ORM projeksiyonu için bir View Value Object oluşturabilirsiniz.

public final class UserListItemView {
    private String id;
    private String firstname;
    private String lastname;
    // Accessors ...
}

Sayfalandırılmış sonucu depo katmanından kolayca alabilirsiniz. Yay sayesinde sadece projeksiyonlar için arayüzler kullanabilirsiniz.

List<UserListItemView> find(Pageable pageable);

Merak etmeyin diğer dönüşüm işlemleri BeanUtils.copyyöntemi gayet iyi çalışıyor.

1. Bana göre sorunun en iyi cevabı bir DTO ne olduğunu DTO en testini gerektiren herhangi bir iş mantığı veya yöntemler uygulanmasını içermemelidir basit nesnelerdir .
2. Normalde modeliniz (MVC desenini kullanarak) akıllı modellerdir ve bu model için özel olarak bazı farklı işlemler yapan birçok / bazı yöntem içerebilir (iş mantığı değil, bu kontrolörlerde olmalıdır). Bununla birlikte, veri aktarırken (örn. Bir yerden bir REST ( GET/ POST/ ne olursa olsun) uç noktası çağırmak veya SOA vb. Kullanarak bir web servisini tüketmek gibi), büyük boyutlu nesneyi, gerekli olmayan kodla iletmek istemezsiniz. uç nokta, veri tüketecek ve aktarımı yavaşlatacaktır.

MVC ile veri aktarım nesneleri genellikle alan modellerini görünüm tarafından görüntülenecek daha basit nesnelerle eşlemek için kullanılır.

Gönderen Vikipedi :

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 nesnesi (DTO) “işlemler arasında veri taşıyan bir nesne” (Wikipedia) veya “verileri kapsüllemek ve bir uygulamanın bir alt sisteminden diğerine göndermek için kullanılan bir nesne” (Yığın Taşması yanıtı) açıklar.

defn

DTO sabit kodlanmış bir veri modelidir. Yalnızca , tüm alanların derleme zamanında bilindiği ve bu nedenle güçlü yazılan özelliklerle erişildiği, sabit kodlu bir üretim süreci tarafından işlenen bir veri kaydının modellenmesi sorununu çözmektedir .

Buna karşılık, dinamik bir model veya "özellik çantası", üretim süreci çalışma zamanında oluşturulduğunda bir veri kaydının modellenmesi sorununu çözer.

Cvar

Bir DTO alanlar veya özelliklerle modellenebilir, ancak biri Cvar adı verilen çok kullanışlı bir veri kabı icat etti. Bir değere referanstır. Bir DTO, referans özellikleri olarak adlandırdığım modelle modellenmişse , modüller yığın belleği paylaşmak ve böylece birlikte çalışmak üzere yapılandırılabilir. Bu, kodunuzdan parametre geçişini ve O2O iletişimini tamamen ortadan kaldırır. Başka bir deyişle, referans özelliklere sahip DTO'lar kodun sıfır kuplaj elde etmesini sağlar .

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

Kaynak: http://www.powersemantics.com/

Dinamik DTO'lar, dinamik yazılım için gerekli bir bileşendir. Dinamik bir işlemi başlatmak için, bir derleyici adımı komut dosyasındaki her makineyi komut dosyasının tanımladığı referans özelliklere bağlamaktır. Dinamik bir DTO, Cvar'ları bir koleksiyona ekleyerek oluşturulur.

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

savlarının

Not: Wix, parametreleri bir "anti-desen" olarak düzenlemek için DTO'ların kullanımını etiketlediğinden, yetkili bir fikir vereceğim.

    return View(model);  // MVC disagrees

İşbirlikçi mimarim tasarım desenlerinin yerini alıyor. Web makalelerime bakın.

Parametreler bir yığın çerçeve makinesinin hemen kontrolünü sağlar. Sürekli kontrol kullanıyorsanız ve bu nedenle hemen kontrole ihtiyaç duymuyorsanız, modüllerinizin parametrelere ihtiyacı yoktur. Mimarimin hiçbiri yok. Makinelerin proses içi konfigürasyonu (metotlar), parametreler değer türleri olduğunda karmaşıklık ve değer (performans) ekler. Bununla birlikte, referans türü parametreleri, tüketicinin önbellek hatalarının değerleri yığıntan almasına neden olur - bu nedenle, tüketiciyi referans özellikleriyle yapılandırın. Makine mühendisliğinden gerçek: parametrelere güvenmek bir tür ön optimizasyondur, çünkü işlemenin (bileşenlerin yapılması) kendisi israftır. Daha fazla bilgi için W makaleme bakın. http://www.powersemantics.com/w.html .

Fowler ve şirket, başka herhangi bir mimari tanıyorlarsa, DTO'ların dağıtılmış mimari dışındaki faydalarını fark edebilir. Programcılar yalnızca dağıtılmış sistemleri bilir. Entegre işbirliği sistemleri (diğer bir deyişle üretim olarak da üretim) kendi mimarim olarak iddia etmem gereken bir şey, çünkü bu şekilde kod yazan ilk kişi benim.

Bazıları DTO'yu anemik bir etki alanı modeli olarak görür, yani işlevselliği yoktur, ancak bu bir nesnenin etkileşimde bulunduğu verilere sahip olması gerektiğini varsayar. Bu kavramsal model daha sonra verileri dağıtılmış işleme modeli olan nesneler arasında iletmeye zorlar. Bununla birlikte, bir üretim hattında, her adım nihai ürüne erişebilir ve sahibi olmadan veya kontrol etmeden değiştirebilir. Dağıtılmış ve tümleşik işleme arasındaki fark budur. Üretim, ürünü operasyonlardan ve lojistikten ayırır.

Lojistik ve geri dönüş sorunlarını ele almak için yarattığı tüm ekstra iş ve baş ağrısı haricinde, bir e-posta izi tutmadan birbirlerine e-posta gönderen işe yaramaz ofis çalışanları olarak modelleme işlemenin doğası gereği yanlış bir şey yoktur. Uygun şekilde modellenmiş bir dağıtılmış işlem, ürüne hangi işlemlerden geldiğini ve gideceğini açıklayan bir belge (etkin yönlendirme) ekler. Etkin yönlendirme, işlem başlamadan önce yazılan işlem kaynağı yönlendirmesinin bir kopyasıdır. Bir arıza veya başka bir acil durum değişikliği durumunda, aktif yönlendirme, gönderileceği işlem adımlarını içerecek şekilde değiştirilir. Bu daha sonra üretime giden tüm emeği açıklar.