Temiz Mimari: Görünüm Modeli Nedir?

Bob Amca, 'Temiz Mimari' kitabında, Sunucunun aldığı verileri 'Modeli Görüntüle' olarak adlandırdığı bir şeye koyması gerektiğini söylüyor.

Model-View-ViewModel (MVVM) tasarım modelinden 'ViewModel' ile aynı şey mi yoksa basit bir Veri Aktarım Nesnesi (DTO) mi?

Eğer öyleyse değil , basit bir DTO, nasıl Görünüm ile ilgisi nedir? Görünüm, bir Observer ilişkisi aracılığıyla ondan güncellemeler alıyor mu?

Benim tahminim daha çok MVVM'den ViewModel'e benziyor, çünkü kitabının 23. Bölümünde Robert Martin şöyle diyor:

[Sunum Yapan Kişinin] işi, uygulamadaki verileri kabul etmek ve bunları sunum için biçimlendirmektir, böylece Görünüm yalnızca ekrana taşıyabilir. Örneğin, uygulama bir alanda görüntülenen bir tarih istiyorsa, Sunum Yapan kişiye bir Tarih nesnesi verir. Presenter daha sonra bu verileri uygun bir dizeye biçimlendirir ve Görünüm modeli adlı basit bir veri yapısına yerleştirir; burada Görünüm bulabilir.

Bu, örneğin bir işlev bağımsız değişkeni olarak (DTO'da olduğu gibi) almanın aksine, Görünüm'ün bir şekilde ViewModel ile bağlantılı olduğu anlamına gelir.

Eğer resmin bakarsak, Sunucu Görünümü Modeli kullanır, ancak çünkü bu düşünmek başka nedeni ise değil Görünüm. Sunum Yapan, hem Çıktı Sınırını hem de Çıktı Verisi DTO'yu kullanır.

MVVM'den ne bir DTO ne de ViewModel değilse, lütfen ne olduğuna dikkat edin.

Model-View-ViewModel (MVVM) tasarım modelindeki 'ViewModel' ile aynı şey mi?

Hayır!

Yani olurdu bu :

Döngüler var. Bob Amca döngüden dikkatli bir şekilde kaçınır .

Bunun yerine:

Kesinlikle döngüleri yok. Ancak bu, görünümün bir güncelleme hakkında nasıl bildiğini merak etmenizi sağlar. Birazdan buna ulaşacağız.

ya da basit bir Veri Aktarım Nesnesi (DTO) mu?

Bob'u bir önceki sayfadan alıntılamak için:

İsterseniz temel yapıları veya basit veri aktarım nesnelerini kullanabilirsiniz. Veya bir hashmap içine paketleyebilir veya bir nesneye inşa edebilirsiniz.

Temiz Mimari p207

Yani, tabii, eğer istersen.

Ama şiddetle gerçekten sizi rahatsız eden şüpheli bu :

UML'nin bu sevimli küçük kötüye kullanımı, kaynak kod bağımlılığının yönünü kontrol akış yönüyle karşılaştırır. Sorunuzun cevabını burada bulabilirsiniz.

Kullanım ilişkisinde:

kontrol akışı, kaynak kod bağımlılığının yaptığı yönde gider.

Uygulama ilişkisinde:

kontrol akışı tipik olarak kaynak kod bağımlılığının tersi yönde ilerler.

Bu, gerçekten buna baktığınız anlamına gelir:

Kontrol akışının Sunum Yapandan Görünüme asla ulaşamayacağını görebilmelisiniz.

Nasıl olabilir? Bu ne demek?

Bu, görünümün kendi iş parçacığına sahip olduğu anlamına gelir (bu olağandışı değildir) veya (@Euphoric işaret ettiği gibi) kontrol akışı, burada tasvir edilmeyen başka bir şeyden görünüme geliyor.

Aynı iş parçacığıysa, Görünüm, Görünüm Modelinin ne zaman okunmaya hazır olduğunu bilecektir. Ancak durum buysa ve görünüm bir GUI ise, kullanıcı DB'yi beklerken ekranı hareket ettirdiğinde ekranı yeniden boyamakta zorlanır.

Görünüm kendi iş parçacığına sahipse, kendi kontrol akışına sahiptir. Bu, Uygulamayı uygulamak için, değişiklikleri fark etmek için Görünüm Modeli'ni sorgulamak zorunda kalacağı anlamına gelir.

Sunucu, Görünüm'ün varlığını ve Görünüm, Sunucu'nun var olduğunu bilmediğinden birbirlerini arayamazlar. Olayları birbirlerine fırlatamazlar. Olabilecek tek şey, Sunucunun View-Model'e yazacağı ve View View-Model'i okuyacağıdır. Ne zaman hissediyorsa.

Bu şemaya göre, View ve Presenter'ın paylaştığı tek şey View-Model hakkında bilgidir. Ve bu sadece bir veri yapısı. Yani herhangi bir davranışı olmasını beklemeyin.

Bu imkansız görünebilir, ancak View-Model karmaşık olsa bile çalışması sağlanabilir. Küçük bir güncellenmiş alan, tüm görünümü bir değişiklik tespit etmek için anket gerekir.

Şimdi elbette gözlemci desenini kullanmakta ısrar edebilir veya bu sorunu sizden gizlemek için bazı çerçeveli şeylere sahip olabilirsiniz, ancak lütfen bunu yapmak zorunda olmadığınızı anlayın.

İşte kontrol akışını gösteren biraz eğlenceli:

Daha önce tanımladığım yönlere göre akışı gördüğünüzde, gördüğünüz şeyin geri dönen bir çağrı olduğunu unutmayın. Bu hile Manzaraya ulaşmamıza yardımcı olmaz. İlk önce Kontrolör olarak adlandırılan şeye dönmezsek. Veya görünümü değiştirebilmeniz için tasarımı değiştirebilirsiniz . Bu aynı zamanda Veri Erişimi ve Arayüzü ile ilgili bir yo-yo sorununun başlangıcını giderir .

Burada öğrenilecek tek şey, Kullanım Senaryosu Kullanıcının sunum yapan kişiyi son çağırdığı sürece istediği sırayla işleri çağırabilmesidir.

Bu sorunu çok kafa karıştırıcı buluyorum ve hem Martin Temiz Mimarisini hem de MVVM'yi yanlış anladığınıza inandığım için sorunu düzgün bir şekilde açıklamak çok fazla metin ve zaman alacaktı.

Dikkat edilmesi gereken ilk şey, gönderdiğiniz şemanın eksik olmasıdır. Yalnızca "iş mantığını" gösterir, ancak parçaları doğru sırada hareket ettiren bir tür "orkestratör" yoktur.

Orkestratör kodu kadar basit olurdu

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

Temiz Mimari konusundaki görüşmelerinden birinde Martin'in bunun hakkında konuştuğunu duyduğuma inanıyorum.

Dikkat çekilmesi gereken başka bir şey, candied_orange'ın döngü eksikliği hakkındaki yorumunun yanlış olduğudur. Evet, döngü kodun mimarisinde mevcut değildir (olmamalıdır). Ancak çalışma zamanı örnekleri arasındaki döngüler yaygındır ve genellikle daha basit bir tasarıma yol açar.

MVVM'de durum böyledir. MVVM View'da ViewModel'e bağlıdır ve ViewModel, View'u değişiklikler hakkında bilgilendirmek için olayları kullanır. Bu, sınıfların tasarımında yalnızca Görünümden Model sınıflarına bağımlılık olduğu, ancak çalışma zamanı sırasında View ve ViewModel örnekleri arasında döngüsel bağımlılık olduğu anlamına gelir. Bu nedenle, ViewModel kendisini ne zaman güncelleyeceğini anlamanın View yolunu sağlayacağı için orkestratöre gerek yoktur. Bu nedenle, bu diyagramdaki "bildirimler", doğrudan değil, "dalgalı" çizgi kullanır. Bu, ViewModel'in View'a bağlı olduğu değil ViewModel'deki değişiklikleri gözlemlediği anlamına gelir.

Martin Temiz Mimarisi'nden almanız gereken en önemli şey tasarımın kendisi değil, bağımlılıkları nasıl ele aldığınızdır. Görüşmelerinde yaptığı kritik noktalardan biri, bir sınır olduğunda, o sınırı geçen tüm kod bağımlılıklarının tek yönde geçmesidir. Diyagramda, bu sınır çift çizgi ile temsil edilir. Ve orada arayüzleri üzerinden bağımlılık ters bir sürü olduğunu ( InputBoundary, OutputBoundaryve DataAccessInterfacebu düzeltmeleri kod bağımlılık yönü).

Bunun aksine, ViewModelTemiz Mimari'de mantıksız, sade bir DTO vardır. Bu, <DS>etiket tarafından açıkça belirtilir . Ve mantık ne zaman çalıştırılacağını bilemeyeceğinden orchestrator, bu neden gereklidir View.

Diyagramı çalışma sırasında neye benzeyeceğine "düzleştirecek olsaydım" şöyle olacaktır:

Bu yüzden çalışma zamanı sırasında bağımlılıklar "yanlış" yöndedir, ancak bu iyidir.

Akıl yürütmesini daha iyi anlamak için Temiz Mimari hakkındaki konuşmasını izlemenizi tavsiye ederim .