MVP'nin MVC'ye göre gelişimi nelerdir?

Model-View-Controller (MVC) ve Model-View-Presenter (MVP) modelleri hakkında üç gündür okudum . Ve beni çok rahatsız eden bir soru var. Yazılım tasarımcıları bir MVC olduğu zaman neden MVP'yi icat ettiler?

Hangi problemlerle karşılaştılar, MVC'nin çözemediğini (ya da kötü bir şekilde çözdüğünü), ancak MVP çözebilir mi? MVP hangi sorunları çözmeyi amaçlamaktadır?

MVP'nin tarihçesi ve açıklaması veya MVC ile MVP arasındaki farklar hakkında birçok makale okudum, ancak hiçbirinin sorularıma açık bir cevabı yoktu.

Okuduğum makalelerin birinde, şöyle söylendi:

Şimdi, modern bileşen tabanlı grafiksel kullanıcı arayüzlerine uygulandığında MVC modelinin yetersizliğine bir cevap olan Model View Presenter üzerine. Modern GUI sistemlerinde, GUI bileşenlerinin kendisi, bazı merkezi denetleyiciler yerine, fare hareketleri ve tıklamalar gibi kullanıcı girişlerini idare eder.

Yani, anlayamıyorum, ama aslında başka bir şekilde olabilir, öyle ki GUI bileşenleri kullanıcı girişlerini kendi başlarına yapamazlar? Ve "kendi başlarına halletmek" tam olarak ne anlama geliyor?

— galip
kaynak

Kopyası stackoverflow.com/questions/2056/...

— qwerty_so

Bence sadece "İmparatorun Yeni Giysileri", Mickeysoft’dan yeni bir kelime.

— qwerty_so

Victor, "neden iki farklı kalıp var?" Dışında özel bir sorunuz var mı? İki farklı model var çünkü aynı problemi iki farklı şekilde çözüyorlar. İşe yararsa, Model ve Görünüm her iki kalıpta da aynıdır. Denetleyici ve Sunucu arasındaki farklara odaklanın. Burada daha fazla yardım bulabilirsiniz: linkedin.com/pulse/…

— Robert Harvey

“Üç gündür MVC ve MVP kalıplarını okudum.” Amanın. Rahatlatıcı bir sıcak banyoya girmenizi veya ördeklerle dolu bir havuza falan taş atlamanızı öneririm. Bu tür bir okuma, herhangi bir pratik uygulama olmadan, beyninizi gerçekten eritebilir!

— user1172763

İstediğiniz cevap türünü almanın yolu bu kalıpları kullanarak bir şeyler inşa etmektir . O zaman aydınlanacaksın.

— Robert Harvey,

Yanıtlar:

MVC kavramsal olarak zarif:

kullanıcı girişi denetleyici tarafından kontrol edilir
denetleyici modeli günceller
Model görünüm / kullanıcı arayüzünü günceller

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Ancak: MVC'deki veri ve olay akışı daireseldir. Ve görünüm genellikle önemli bir mantık içerecektir (kullanıcı eylemleri için olay işleyicileri gibi). Birlikte, bu özellikler sistemi test etmeyi zorlaştırır ve bakımını zorlaştırır.

MVP mimarisi, denetleyici ile görünüm ve model arasında arabuluculuk yapan bir sunucuyu değiştirir. Bu, sistemi doğrusallaştırır:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Bunun aşağıdaki avantajları vardır:

Mantık (olay işleyicileri ve kullanıcı arayüzü durumu gibi) görünümden sunum yapan kişiye taşınabilir.
Kullanıcı arayüzü, kullanıcı arayüzü durumunu açıkladığından, sunucu açısından test edilebilir. Ünite testinde, görüntüyü sunum yapan kişiye yapılan bir test sürücüsüyle değiştiririz.
Kullanıcı arayüzü uygulama mantığından izole edildiğinden her ikisi de bağımsız olarak geliştirilebilir.

Ancak bu yaklaşımın bazı dezavantajları da var:

Daha fazla çaba gerektiriyor.
Sunucu kolayca sürdürülemez bir “tanrı sınıfına” dönüşebilir.
Uygulamanın tek bir MVP ekseni değil, birden çok ekseni vardır: kullanıcı arayüzündeki her ekran / pencere / panel için bir tane. Bu, mimarinizi basitleştirebilir veya çok fazla karmaşıklaştırabilir.

— amon
kaynak

İyi cevap, ancak günümüzün MVC'si (belki de varsa) olay işleyicilerini genellikle yerel form doğrulaması dışında pek bir şekilde kullanmaz ve bu olayları MVC'nin bir parçası olarak görmüyorum. Bu yüzden MVP ve MVVM'lerimiz var. MVC esasen sunucu tarafındadır.

— Robert Harvey,

@amon, cevabınız için teşekkür ederim, bana çok şey söylüyor. Ve, uygulamada birkaç eksene sahip olmanın mimariyi basitleştirebileceğinden bahsedersiniz. Bu fikri birçok makalede karşıladım ve MVP'yi icat etmenin ana nedenlerinden biri olarak bahsedildi, çünkü MVC karmaşık GUI gereksinimlerini karşılamıyor. Bu, MVP'nin hangi gereksinimleri karşıladığı ve bu gereksinimleri nasıl çözdüğüdür? Kalıcı olduğum için üzgünüm, ama ben gerçekten iyi bir şekilde anlamak için asadım.

— Victor,

@Victor En iyi örüntü yok, ancak takaslar farklı. MVC, karmaşık gereksinimler için bir eşleşme olabilir. Mimarlık açısından MVP, görüşler ve sunum yapanlar arasında 1: 1 ilişki kurar: her görünümün kendi sunucusu vardır, her sunucu bir görünüme bağlanır. MVC'de bir n: m ilişkisi vardır: Bir görünüm kullanıcı girişini birden fazla farklı kontrol cihazına gönderebilir ve bir kontrol birimi birçok görünümden giriş alabilir. Bu daha esnektir, fakat aynı zamanda daha kaotiktir - MVC'de net bir "eksen" yoktur.

— amon

@Victor GUI'lerde fazla tecrübem yok, bu yüzden muhtemelen bahsetmediğim çok şey var. Yaptığım son GUI mutlak bir karışıklıktı, çünkü o noktada MVP'yi bilmiyordum - doğrusallaştırılmış bir veri ve kontrol akışı büyük bir gelişme olurdu.

— amon

@RobertHarvey Webin "MVC" dediği şeyin, orijinal tanımı ile asla "MVC" olmadığını iddia ediyorum. Kısaltmayı kim kaçırdıysa, yüklü bir terim seçip herkesin kafasını karıştırdığı için başın üstüne çarpılmalıdır.

— jpmc26

MVP'de, Presenter, MVC'nin Kontrolörünün yerine geçer. İkisi arasındaki fark, Sunucunun Görünümü doğrudan değiştirmesidir. MVVM kalıbına (WPF gibi) ödün verebilecek zengin veri bağlama için ağır destek olmadan, öncelikle olaya dayalı (Windows Forms gibi) UI çerçeveleri için tasarlanmıştır. Aksi halde, görünüm durumunu yönetme ve destekleme modelini güncelleme mantığının çoğu, görünümün kendisinde yatmaktadır.

— Michael Brown
kaynak