Hizmetler her zaman DTO'ları döndürmeli mi, yoksa etki alanı modelleri de döndürebilir mi?

Büyük ölçekli bir uygulama tasarlıyorum, DDD tabanlı çok katmanlı mimari kullanıyoruz.

Veri katmanı (depoların uygulanması), etki alanı katmanı (alan modeli ve arayüzlerin tanımı - depolar, hizmetler, iş birimi), hizmet katmanı (hizmetlerin uygulanması) ile MVC'ye sahibiz. Şimdiye kadar, tüm katmanlarda etki alanı modelleri (çoğunlukla varlıklar) kullanıyoruz ve DTO'ları yalnızca görünüm modelleri olarak kullanıyoruz (denetleyicide, hizmet etki alanı model (ler) i ve denetleyici, görünüme geçirilen görünüm modeli oluşturur).

DTO'ları kullanma, kullanma, haritalama ve aktarma hakkında sayısız makale okudum. Kesin bir yanıt olmadığını anlıyorum, ancak etki alanı modellerini hizmetlerden denetleyicilere geri döndürüp döndürmediğinden emin değilim. Etki alanı modelini döndürürsem, denetleyici her zaman görünüme özgü görünüm modeli oluşturduğundan hala görünüme geçmez - bu durumda yasal görünüyor. Öte yandan, etki alanı modeli iş katmanından (hizmet katmanı) ayrıldığında doğru gelmiyor. Bazen hizmetin etki alanında tanımlanmayan veri nesnesini döndürmesi gerekir ve daha sonra eşlenmeyen etki alanına yeni nesne eklememiz veya POCO nesnesi oluşturmamız gerekir (bu, bazı hizmetler etki alanı modelleri döndürdüğü için çirkin olur. etkili bir şekilde DTO'lar döndürür).

Soru - kesinlikle görünüm modellerini kullanırsak, etki alanı modellerini denetleyicilere kadar döndürmek uygun mudur, yoksa hizmet katmanıyla iletişim için her zaman DTO'ları kullanmalı mıyız? Öyleyse, alan adı modellerini hangi hizmetlerin gereksinimine göre ayarlamak uygun mudur? (Açıkçası öyle düşünmüyorum, çünkü hizmetler hangi alanın sahip olduğunu tüketmelidir.) Eğer DTO'lara sıkı sıkıya bağlı kalsak, hizmet katmanında tanımlanmalı mıdır? (Sanırım.) Bazen DTO'ları kullanmamız gerektiği açıktır (örneğin, hizmet çok fazla iş mantığı gerçekleştirdiğinde ve yeni nesneler oluşturduğunda), bazen sadece etki alanı modellerini kullanmamız gerektiği açıktır (örneğin, Üyelik hizmeti anemik Kullanıcı ( s) - etki alanı modeliyle aynı olan DTO oluşturmak pek mantıklı görünmüyor) - ama tutarlılığı ve iyi uygulamaları tercih ediyorum.

Makale Domain vs DTO vs ViewModel - Nasıl ve Ne Zaman Kullanılır? (ve diğer bazı makaleler) sorunuma çok benziyor, ancak bu sorulara cevap vermiyor. Makale DTO'ları EF ile veri havuzunda mı uygulamalıyım? benzerdir, ancak DDD ile ilgilenmez.

Feragatname: Herhangi bir tasarım desenini sadece var olduğu ve süslü olduğu için kullanmayı düşünmüyorum, öte yandan, uygulamayı bir bütün olarak tasarlamaya yardımcı olduğu, ayrılmaya yardımcı olduğu için de iyi tasarım desenleri ve uygulamaları kullanmak istiyorum. Endişe, belirli bir desen kullanmak zor olsa da, en azından şu anda "gerekli" değildir.

Her zaman olduğu gibi teşekkür ederim.

etki alanı modeli iş katmanından (hizmet katmanı) ayrıldığında doğru gelmiyor

Bağırsakları doğru çektiğini hissettiriyor mu? Martin Fowler'e göre: Hizmet Katmanı uygulamanın sınırlamasını tanımlar, etki alanını kapsar. Başka bir deyişle, etki alanını korur.

Bazen hizmetin, etki alanında tanımlanmayan veri nesnesini döndürmesi gerekir

Bu veri nesnesine bir örnek verebilir misiniz?

DTO'lara sıkı sıkıya bağlı kalsak, hizmet katmanında tanımlanmalı mıdır?

Evet, çünkü yanıt hizmet katmanınızın bir parçasıdır. "Başka bir yerde" olarak tanımlanmışsa, hizmet katmanının bu "başka bir yere" referans vermesi ve lazona yeni bir katman eklemesi gerekir.

etki alanı modellerini denetleyicilere kadar döndürmek uygun mudur, yoksa hizmet katmanıyla iletişim için her zaman DTO'ları kullanmalı mıyız?

DTO bir yanıt / istek nesnesidir, iletişim için kullanırsanız mantıklıdır. Sunum katmanınızda (MVC-Denetleyicileri / Görünüm, WebForms, ConsoleApp) etki alanı modelleri kullanıyorsanız, sunum katmanı etki alanınıza sıkıca bağlanırsa, etki alanındaki tüm değişiklikler denetleyicilerinizi değiştirmenizi gerektirir.

alan modeliyle aynı olan DTO oluşturmak pek mantıklı görünmüyor)

Bu DTO'nun yeni gözlere dezavantajlarından biridir. Şu anda, kodun kopyalanmasını düşünüyorsunuz , ancak projeniz genişledikçe, özellikle farklı ekiplerin farklı katmanlara atandığı bir takım ortamında çok daha mantıklı olacaktır.

DTO, uygulamanıza ek karmaşıklık katabilir, ancak katmanlarınız da eklenebilir. DTO sisteminizin pahalı bir özelliğidir, ücretsiz gelmezler.

Neden DTO kullanılır

Bu makale bir DTO kullanmanın hem avantajını hem de dezavantajını sağlar, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html

Özet aşağıdaki gibidir:

Ne Zaman Kullanılır

• Büyük projeler için.
• Proje ömrü 10 yıl ve üzerindedir.
• Stratejik, kritik görev uygulaması.
• Büyük takımlar (5'ten fazla)
• Geliştiriciler coğrafi olarak dağıtılır.
• Alan adı ve sunum farklıdır.
• Genel veri alışverişini azaltın (DTO'nun asıl amacı)

Ne Zaman Kullanılmamalıdır

• Küçük - orta boy proje (maksimum 5 üye)
• Proje ömrü 2 yıldır.
• GUI, arka uç vb.İçin ayrı bir ekip yok.

DTO'ya Karşı İddialar

• Kod çoğaltılması.
• Geliştirme zamanının maliyeti, hata ayıklama. (DTO oluşturma araçlarını kullanın http://entitiestodtos.codeplex.com/ )
• Her iki modeli de her zaman senkronize etmelisiniz.
• Geliştirme maliyeti: Ek haritalama gereklidir. ( https://github.com/AutoMapper/AutoMapper gibi otomatik haritacıları kullanın )
• Veri Aktarım Nesneleri neden bir anti-desen?

DTO ile Bağımsız Değişkenler

• DTO olmadan, sunum ve etki alanı sıkı bir şekilde birleştirilir. (Bu küçük projeler için uygundur.)
• Arayüz / API kararlılığı
• Yalnızca kesinlikle gerekli olan öznitelikleri içeren bir DTO döndürerek sunum katmanı için optimizasyon sağlayabilir. Linq projeksiyonunu kullanarak , tüm objeyi çekmek zorunda değilsiniz.
• Geliştirme maliyetini azaltmak için kod oluşturma araçlarını kullanın

DDD yaklaşımından geçmeye karar verdiğiniz için uygulamanız yeterince büyük ve karmaşık görünüyor. Hizmet katmanınızdaki poco varlıklarınızı veya etki alanı varlıklarını ve değer nesnelerini döndürmeyin. Bunu yapmak istiyorsanız, artık ihtiyacınız olmadığından hizmet katmanınızı silin! Görünüm Modeli veya Veri aktarımı nesneleri, etki alanı modeli üyeleriyle eşleşmeleri veya tam tersi olması nedeniyle Hizmet katmanında yaşamalıdır. Öyleyse neden DTO'ya ihtiyacınız var? Çok sayıda senaryo içeren karmaşık uygulamada, etki alanı ve sunum görünümlerinin endişelerini ayırmalısınız, bir etki alanı modeli birkaç DTO'ya bölünebilir ve ayrıca birkaç Etki Alanı modeli bir DTO'ya daraltılabilir. Bu nedenle, modelinizle aynı olsa bile DTO'nuzu katmanlı mimaride oluşturmak daha iyidir.

Hizmet katmanıyla iletişim için her zaman DTO'ları kullanmalı mıyız? Evet, etki alanı modeli üyeleriyle hizmet katmanındaki deponuzla konuştuğunuzda DTO'yu hizmet katmanınız tarafından döndürmeniz ve bunları DTO'ya eşlemeniz ve MVC denetleyicisine geri dönmeniz veya tersini yapmanız gerekir.

Etki alanı modellerini hangi hizmetlerin gereksinimine göre ayarlamak uygun mudur? Bir hizmet sadece depo ve etki alanı yöntemleriyle ve etki alanı hizmetleriyle konuşur, etki alanınızdaki işletmeyi gereksinimlerinize göre çözmelisiniz ve etki alanına neyin gerekli olduğunu söylemek hizmet görevi değildir.

DTO'lara sıkı sıkıya bağlı kalsak, hizmet katmanında tanımlanmalı mıdır? Evet, hizmet katmanındaki etki alanı üyelerine eşlenmeleri gerektiğinden DTO veya ViewModel'i daha sonra hizmete almayı deneyin ve DTO'yu uygulamanızın denetleyicilerine yerleştirmek iyi bir fikir değildir ( Hizmet katmanınızda Yanıt İsteği kalıbı kullanmaya çalışın ), şerefe !

Deneyimlerime göre pratik olanı yapmalısınız. "En iyi tasarım işe yarayan en basit tasarımdır" - Einstein. Bu zihinle ...

Kesinlikle görünüm modellerini kullanırsak, etki alanı modellerini denetleyicilere kadar döndürmek uygun mudur, yoksa hizmet katmanıyla iletişim için her zaman DTO'ları kullanmalı mıyız?

Kesinlikle sorun yok! Etki Alanı Varlıkları, DTO'lar ve Görünüm Modelleri varsa, veritabanı tabloları dahil olmak üzere uygulamadaki tüm alanları 4 yerde tekrarlayabilirsiniz. Etki Alanı Varlıkları ve Görünüm Modellerinin iyi çalıştığı büyük projelerde çalıştım. Bunun tek istisnası, uygulamanın dağıtılmış olması ve hizmet katmanının başka bir sunucuda bulunmasıdır; bu durumda DTO'ların serileştirme nedenleriyle kablo üzerinden gönderilmesi gerekir.

Öyleyse, alan adı modellerini hangi hizmetlerin gereksinimine göre ayarlamak uygun mudur? (Açıkçası öyle düşünmüyorum, çünkü hizmetler alan adının ne olduğunu tüketmelidir.)

Genellikle kabul eder ve hayır derim çünkü Domain modeli genellikle iş mantığının bir yansımasıdır ve genellikle bu mantığın tüketicisi tarafından şekillenmez.

DTO'lara sıkı sıkıya bağlı kalsak, hizmet katmanında tanımlanmalı mıdır? (Sanırım.)

Onları kullanmaya karar verirseniz kabul ediyorum ve evet diyorum, hizmet katmanı günün sonunda DTOs döndürüyor gibi mükemmel bir yerdir.

İyi şanslar!

Bu partiye geç kaldım, ama bu çok yaygın ve önemli bir soru.

"Hizmetler" ile mavi kitapta Evan's tarafından tanımlanan "Uygulama Katmanı" mı kastedilmektedir ? Sana bu durumda cevap onlar gerektiğidir yapmak varsayıyoruz değil DTOs dönün. Mavi alandaki "Etki Alanını Ayırma" başlıklı 4. bölümü okumanızı öneririm.

Bu bölümde Evans katmanlar hakkında şunları söylüyor:

Karmaşık bir programı katmanlara ayırın. Her katmanın içinde, yalnızca aşağıdaki katmanlara bağlı olan ve uyumlu bir tasarım geliştirin.

Bunun için iyi bir sebep var. Kısmi düzen kavramını yazılım karmaşıklığının bir ölçüsü olarak kullanırsanız, bir katmanın üstündeki bir katmana bağlı olması, karmaşıklığı artırır, bu da sürdürülebilirliği azaltır.

Bunu sorunuza uyguladığınızda, DTO'lar gerçekten Kullanıcı Arayüzü / Sunum katmanı ile ilgili bir bağdaştırıcıdır. Uzaktan / çapraz süreç iletişiminin tam olarak bir DTO'nun amacı olduğunu unutmayın (bu yazıda, aynı zamanda DDD dilinden bahsetmese de, DTO'ların bir hizmet katmanının parçası olmalarına karşı olduğunu da belirtmek gerekir).

Uygulama katmanınız bu DTO'lara bağlıysa, kendisinin üstündeki bir katmana bağlıdır ve karmaşıklığınız artar. Bunun, yazılımınızı korumanın zorluğunu artıracağını garanti edebilirim.

Örneğin, sisteminiz her biri kendi DTO'su gerektiren diğer birkaç sistem veya istemci türüyle arayüz oluşturuyorsa ne olur? Uygulama hizmetinizin hangi DTO yönteminin geri dönmesi gerektiğini nasıl anlarsınız? Tercih ettiğiniz dil, dönüş türüne göre bir yöntemin (bu durumda servis yöntemi) aşırı yüklenmesine izin vermiyorsa bu sorunu nasıl çözebilirsiniz? Bir yol bulsanız bile, bir Sunum katmanı sorununu desteklemek için Uygulama Katmanınızı neden ihlal ediyorsunuz?

Pratik açıdan, bu bir spagetti mimarisi ile sona erecek bir yolda bir adımdır. Kendi deneyimlerimde bu tür bir devrim ve sonuçlarını gördüm.

Şu anda çalıştığım yerde, Uygulama Katmanımızdaki hizmetler etki alanı nesnelerini döndürüyor. Bu Arabirimi beri bir sorun olarak görmüyorum (yani UI / Sunum) tabakasıdır Alan katmanında, bağlı olduğu aşağıda bunun. Ayrıca, bu bağımlılık "yalnızca başvuru" türüne bağımlıdır, çünkü:

a) Arayüz Katmanı, bu Etki Alanı nesnelerine yalnızca Uygulama katmanına yapılan çağrılarla elde edilen salt okunur dönüş değerleri olarak erişebilir

b) Uygulama Katmanı'ndaki hizmetlere ilişkin yöntemler, yalnızca katmanda "ham" girdi (veri değerleri) veya nesne parametreleri (gerektiğinde parametre sayısını azaltmak için) olarak kabul eder. Özellikle, uygulama hizmetleri Etki Alanı nesnelerini hiçbir zaman girdi olarak kabul etmez.

Arayüz Katmanı, Etki Alanı nesnelerinden DTO'lara eşlemek için Arayüz Katmanı içinde tanımlanan eşleme tekniklerini kullanır. Yine, bu DTO'ları Arayüz Katmanı tarafından kontrol edilen adaptörler olmaya odaklar.

Partiye geç kaldım, ama tam olarak aynı tür mimariyle karşı karşıyayım ve “sadece hizmetten DTO'lar” a yöneliyorum. Bunun temel nedeni, yalnızca nesne içindeki geçerliliği korumak için etki alanı nesnelerini / toplamalarını kullanmaya karar vermiş olmamdır, bu nedenle yalnızca güncelleme, oluşturma veya silme sırasında. Verileri sorgularken EF'i yalnızca depo olarak kullanırız ve sonucu DTO'larla eşleştiririz. Bu, genellikle hızlı oldukları gibi veritabanı işlevlerini kullanarak, okuma sorgularını optimize etmemize ve bunları iş nesnelerine uyarlamamıza izin verir.

Her hizmet yöntemi kendi sözleşmesini tanımlar ve bu nedenle zaman içinde bakımı daha kolaydır. Umuyorum.

Şimdiye kadar, tüm katmanlarda etki alanı modelleri (çoğunlukla varlıklar) kullanıyoruz ve DTO'ları yalnızca görünüm modelleri olarak kullanıyoruz (denetleyicide, hizmet etki alanı model (ler) i ve denetleyici, görünüme geçirilen görünüm modeli oluşturur).

Etki Alanı Modeli, tüm uygulamanız için terminoloji ( Ubiquitous Language ) sağladığı için Etki Alanı Modelini yaygın olarak kullanmak daha iyidir.

ViewModels / DTO'ları kullanmanın tek nedeni , uygulamanızda (her türlü sunum katmanı) ve (Alan Modeli) ayırmak için MVC kalıbının uygulanmasıdır . Bu durumda sunumunuz ve alan adı modeliniz gevşek bir şekilde birleştirilir.ViewModel

Bazen hizmetin etki alanında tanımlanmamış veri nesnesini döndürmesi gerekir ve ardından eşlenmeyen etki alanına yeni nesne eklememiz veya POCO nesnesi oluşturmamız gerekir (bazı hizmetler etki alanı modellerini döndürdüğü için bu çirkin, bazı etkili bir şekilde DTO'lar döndürür).

Application / Business / Domain Logic hizmetleri hakkında konuştuğunuzu varsayıyorum.

Mümkün olduğunda alan adı varlıklarını iade etmenizi öneririm. Ek bilgi döndürmek gerekirse, birkaç etki alanı varlığını barındıran DTO döndürmek kabul edilebilir.

Bazen, etki alanı varlıkları üzerinden proxy oluşturan 3. bölüm çerçeveler kullanan kişiler, hizmet alanlarından etki alanı varlıklarını göstermekte zorluklarla karşılaşırlar, ancak bu yalnızca yanlış kullanım sorunudur.

Soru - kesinlikle görünüm modellerini kullanırsak, etki alanı modellerini denetleyicilere kadar döndürmek uygun mudur, yoksa hizmet katmanıyla iletişim için her zaman DTO'ları kullanmalı mıyız?

Etki alanı varlıklarını% 99,9 oranında iade etmenin yeterli olduğunu söyleyebilirim.

DTO'ların oluşturulmasını kolaylaştırmak ve etki alanı varlıklarınızı bunlarla eşleştirmek için AutoMapper kullanabilirsiniz .

Etki alanı modelinizin bir kısmını döndürürseniz, bu bir sözleşmenin bir parçası haline gelir. Bir kontrat değiştirmek, bağlamınız dışındaki şeyler ona bağlı olduğundan zordur. Bu nedenle, alan adı modelinizin bir parçasının değiştirilmesini zorlaştırırsınız.

Bir etki alanı modelinin çok önemli bir yönü, değiştirilmesinin kolay olmasıdır. Bu bizi alan adının değişen gereksinimlerine esnek hale getiriyor.

Bu iki soruyu analiz etmenizi öneririm:

1. Üst katmanlarınız (ör. Modelleri / denetleyicileri görüntüleme ve görüntüleme) verileri, alan katmanının gösterdiklerinden farklı bir şekilde mi tüketiyor? Çok fazla haritalama veya hatta mantık varsa, tasarımınızı tekrar gözden geçirmenizi öneririm: muhtemelen verilerin gerçekte nasıl kullanıldığına daha yakın olmalıdır.

2. Üst katmanlarınızı derinden değiştirme olasılığınız nedir? (örn. WPF için ASP.NET'in değiştirilmesi). Bu durumdan çok farklıysa ve mimariniz çok karmaşık değilse, olabildiğince çok alan varlığını ifşa etmekten daha iyi olabilirsiniz.

Korkarım ki bu oldukça geniş bir konu ve gerçekten sisteminizin ne kadar karmaşık olduğuna ve gereksinimlerine bağlı.

Deneyimlerime göre, bir OO UI deseni (çıplak nesneler gibi) kullanmadığınız sürece, etki alanı nesnelerini UI'ye maruz bırakmak kötü bir fikirdir. Çünkü uygulama büyüdükçe, kullanıcı arayüzünden gelen ihtiyaçlar değişir ve nesnelerinizi bu değişikliklere uyum sağlamaya zorlar. Sonunda iki usta hizmet ediyorsunuz: çok acı verici bir deneyim olan UI ve DOMAIN. İnanın bana, orada olmak istemezsiniz. Kullanıcı arabirimi modeli, kullanıcı ile iletişim kurma işlevine sahiptir, iş kurallarını korumak için DOMAIN modeli ve kalıcılık modelleri, verilerin etkili bir şekilde depolanmasıyla ilgilenir. Hepsi uygulamanın farklı ihtiyaçlarına hitap eder. Bu konuda bir blog yazısı yazmanın ortasındayım, bittiğinde ekleyeceğim.