DTO = ViewModel?

Etki alanı nesnelerimi sürdürmek için NHibernate kullanıyorum. İşleri basit tutmak için hem sunum katmanım hem de hizmet katmanım olarak bir ASP.NET MVC projesi kullanıyorum.

Etki alanı nesnelerimi denetleyici sınıflarımdan XML olarak döndürmek istiyorum. Burada Stack Overflow'da bazı yazıları okuduktan sonra DTO'ların gitmenin yolu olduğunu anladım. Bununla birlikte, ViewModel hakkında konuşan gönderilere de rastladım.

Sorum: Veri Aktarım Nesneleri ve ViewModels aynı şey midir? Yoksa ViewModel, bir DTO'nun bir tür alt kalıbı mıdır?

Bir DTO'nun kanonik tanımı, herhangi bir davranışı olmayan bir nesnenin veri şeklidir.

ViewModels, görünümün modelidir. ViewModel'ler tipik olarak, bir veya daha fazla nesneden (veya DTO'lardan) alınan tam veya kısmi veriler artı görünümün davranışına özgü ek üyelerdir (görünüm tarafından yürütülebilen yöntemler, görünüm öğelerinin nasıl değiştirildiğini gösteren özellikler vb ...). Görünüm modeline, bir görünüm artı davranışlar için tüm veriler olarak bakabilirsiniz. ViewModels, bire bir iş nesneleri veya DTO'larla eşleşebilir veya eşleşmeyebilir.

Bu arada, belirli bir görünüm modelinin kalıcı bir nesneden gelen verilerin bir alt kümesine ihtiyacı varsa , NHibernate projeksiyonları işe yarar.

ASP.NET MVC uygulamasındaki ViewModel, DTO ile aynıdır, ancak MVVM modelindeki ViewModel, DTO'dan farklıdır çünkü MVVM'deki ViewModel davranışlara sahiptir, ancak DTO'da yoktur.

DTO! = ViewModel

Gelen MVVM desen ViewModel adlı Modeli izole etmek için kullanılır. Modeli temsil etmek için, örneğin NHibernate aracılığıyla bir veritabanına eşlenen basit DTO sınıflarını kullanabilirsiniz . Ama bir DTO olarak modellenen bir ViewModel sınıfı hiç görmedim .. ViewModel sınıfları çoğunlukla DTO'ların sahip olmadığı davranışlara sahiptir.

DTO - Veri Aktarım Nesneleri tam da söylediği gibi veri aktarımı için konteynerlerdir. Hiçbir davranışları yoktur, sadece bir grup kurucu ve alıcı vardır. Bazı insanlar onları değişmez kılar ve mevcut olanları güncellemek yerine gerektiğinde yenilerini oluşturur. Kablo üzerinden aktarıma izin vermek için serileştirilebilir olmaları gerekir.

Genel olarak DTO'lar, uzak bir hizmete yapılan çağrılar pahalı olabileceğinden, bir katmandan diğer katmana verileri işlem sınırları boyunca göndermek için kullanılır, bu nedenle gerekli tüm veriler bir DTO'ya gönderilir ve istemciye bir yığın halinde (kaba taneli) aktarılır.

Bununla birlikte, bazı insanlar ekrana bağlı DTO'lar kavramını kullanır (işlem sınırlarını geçme ile ilgisi yoktur). Yine bunlar gerekli verilerle doldurulur (genellikle belirli bir ekran için gereken veriler ve çeşitli kaynaklardan gelen verilerin bir toplamı olabilir) ve müşteriye gönderilir.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

Daha önce belirtildiği gibi basit durumlarda bu DTO, görünüme bağlanmak için kullanılabilir, ancak daha karmaşık durumlarda bir ViewModel oluşturulmasını ve DTO'dan ViewModel'e verilerin boşaltılmasını gerektirir ki bu açıkça daha fazla iştir (MVVM modelini uygularken) .

Yine daha önce belirtildiği gibi DTO! = ViewModel

ve

DTO ve ViewModel'in yaşamda farklı amaçları vardır

İlk olarak, en büyük fark, ViewModel'in DTO'nun Olmaması Gereken davranışlara veya yöntemlere sahip olabilmesidir !!!

İkinci olarak, ASP.NET MVC'de DTO'yu bir ViewModel olarak kullanmak, uygulamanızı DTO ile sıkı bir şekilde birleştirir ve bu, DTO kullanmanın tam tersi bir amaçtır. Bunu yaparsanız, etki alanı Modelinizi veya DTO'nuzu kullanmanın farkı nedir, bir anti-model elde etmek için daha fazla karmaşıklık?

ASP.NET'teki ViewModel, doğrulama için DataAnnotations'ı da kullanabilir.

Aynı DTO, farklı ViewModels Mapping'e sahip olabilir ve One ViewModel, farklı DTO'lardan oluşturulabilir (kompozisyon değil, her zaman nesne haritalama ile). çünkü bir DTO içeren bir ViewModel'e sahipseniz daha da kötü olduğunu düşünüyorum, aynı sorunu yaşayacağız.

Sunum katmanınızdan, DTO'yu bir sözleşme olarak düşünün, uygulamanıza yabancı olduğunu düşünmeniz gereken ve üzerinde herhangi bir kontrolünüz olmayan bir nesne alacaksınız (eski hizmet, dto ve sunum katmanlarına sahip olsanız bile) senindir).

Son olarak, bu temiz ayrımı yaparsanız, geliştiriciler kolaylıkla birlikte çalışabilirler. ViewModel'ları, Görünümleri ve Denetleyicileri tasarlayan kişinin, hizmet katmanı veya DTO uygulaması hakkında endişelenmesine gerek yoktur çünkü diğer geliştiriciler uygulamalarını bitirdiğinde haritalama yapacaktır ... test verileri içeren sunum katmanı.

Bazı basit görünümler için DTO'umu modellerim olarak kullanacağım, ancak Görünümler daha karmaşık hale geldikçe ViewModel'ler oluşturacağım.

Benim için bu, çabukluk (zaten sahip olduğum için DTO kullanmak) ve esneklik (ViewModellerin oluşturulması endişelerin daha fazla ayrılması demektir) arasında bir dengedir.

DTO'yu ViewModel olarak kullanacaksanız, bu, herhangi bir nedenle DTO'yu değiştirdiğiniz için DTO'ya yüksek bağımlılık yaptığınız anlamına gelir, o zaman bu ViewModel'i etkileyebilir.

DTO kullanın ve görünüm modeline dönüştürün.

DTO kullanabilirizModel sınıfıyla aynıdır ve birden çok model verisini / özelliğini tek bir görünümde göstermemiz / kullanmamız gerektiğinde viewmodel'i kullanabiliriz. Örnek: Önce varlık çerçeve veritabanını kullanarak bir model oluşturuyorum. Yani artık tüm model veritabanına göre üretiliyor. ve şimdi veri açıklamasına ihtiyacımız var, bu veri ek açıklamaları için bir klasör adı DTO oluşturabiliriz, Bu DTO klasöründe, özelliğin üzerine veri ek açıklamasını zaten oluşturan ve ekleyen tüm modelleri tam olarak tutabiliriz. Daha sonra bu DTO sınıflarını kullanarak herhangi bir işlemi (denetleyici, görünümleri kullanın) kullanabiliriz. Ve karmaşık görünüme ihtiyaç duyduğumuzda, yani bir görünümde birden çok sınıf verisine ihtiyacımız olduğunda, burada görünüm modelini kullanabiliriz. Viewmodel için bir klasör adı görünüm modeli oluşturabilir, ardından özel bir sınıf oluşturabilir ve ihtiyacımız olan özelliği koruyabiliriz. Kendimi temizlemeye çalıştım. Herhangi bir öneri çok takdir edildi.