22 Soru: MVP ve MVC nedir ve fark nedir?

tarafından oluşturulan soru Mon, May 4, 2015 12:00 AM

Kullanıcı arabirimleri oluşturmanın RAD (sürükle bırak ve yapılandır) yönteminin ötesine bakarken birçok araç, adlı üç tasarım desenine rastlamanızı teşvik eder Model-View-Controller , Model Görünümü -Presenter ve Model-View-ViewModel . Sorumun üç bölümü var:

  1. Bu kalıplar hangi sorunları ele alıyor?
  2. Nasıl benzerler?
  3. Nasıl farklılar?
2021
  1. 2016-12-11 16: 51: 08Z
  2. IDK, ancak sözde orijinal MVC için küçüklerde kullanılması amaçlanmıştır. Her düğme, etiket vb. Kendi görüş ve denetleyici nesnesine sahipti veya en azından Bob Amca'nın iddia ettiği gibi. Galiba Smalltalk hakkında konuşuyordu. YouTube'daki görüşmelerine bakın, büyüleyici.
    2017-09-03 01: 19: 59Z
  3. MVP, View-Controller’ı bir View ve Presenter’a bölerek ekstra bir yönlendirme katmanı ekler ...
    2018-01-26 02: 33: 20Z
  4. Asıl fark, MVC'de Kontrolörün Modelden Görünüme herhangi bir veri iletmemesidir. Sadece Modelden verileri almak için Görünümü bilgilendirir. Bununla birlikte, MVP'de Görünüm ile Model arasında bağlantı yoktur. Presenter, Modelden ihtiyaç duyulan tüm verileri alır ve göstermek için Görüntüye iletir. Buna ek olarak, tüm mimari kalıplardaki bir android örneği ile birlikte burada: digigene.com/kategori /android /android-mimari
    2018-03-19 11: 49: 00Z
  5. Bunlara tasarım desenleri yerine mimari kalıplar denir. Farkı bilmek istiyorsanız, bunu inceleyin
    2019-06-02 22: 17: 14Z
22 Yanıtlar                              22                         

Model-View-Presenter

MVP 'de, Presenter, Görünüm için UI işletme mantığını içerir. Görünüm temsilcisinden gelen tüm çağrılar doğrudan Presenter'a gönderilir. Presenter ayrıca doğrudan Görünümden ayrıştırılır ve bir arayüz aracılığıyla onunla konuşur. Bu, ünitenin testinde Görünümün takılmasını sağlamak içindir. MVP'nin ortak özelliklerinden biri, çok fazla iki yönlü gönderimin olması gerektiğidir. Örneğin, birisi "Kaydet" düğmesini tıkladığında, olay işleyicisi Presenter'ın "OnSave" yöntemine atanır. Kaydetme işlemi tamamlandıktan sonra Presenter, Görünümün kaydetme işleminin tamamlandığını görüntüleyebilmesi için Arayüzü üzerinden Görünümünü geri çağırır.

MVP, Web Formlarında ayrı bir sunum yapmak için çok doğal bir model olma eğilimindedir. Bunun nedeni, görünümün her zaman önce ASP.NET çalışma zamanı tarafından yaratılmış olmasıdır. her iki değişken hakkında daha fazla bilgi edinin .

İki birincil varyasyon

Pasif Görünüm: Görünüm mümkün olduğunca aptal ve neredeyse sıfır mantık içeriyor. Sunucu, Görünüm ve Model ile konuşan ortadaki bir adamdır. Görünüm ve Model birbirinden tamamen korumalı. Model, olayları artırabilir, ancak Presenter, Görünümü güncellemek için bunlara abone olur. Pasif Görünüm'de, Vie yerine doğrudan veri bağlama yoktur.w, Presenter'ın verileri ayarlamak için kullandığı ayarlayıcı özelliklerini gösterir. Tüm durumlar Görünümde değil Presenter'da yönetilir.

  • Pro: maksimum test edilebilirlik yüzeyi; Görünüm ve Modelin temiz ayrılması
  • Con: tüm verileri kendiniz bağladığınız için daha fazla iş (örneğin tüm ayarlayıcı özellikleri).

Denetleyici Denetleyici: Presenter kullanıcı hareketlerini gerçekleştirir. Görünüm, veri bağlama yoluyla doğrudan Modele bağlanır. Bu durumda, Modelin Görünümden geçmesini sağlamak için Sunucunun işidir. Presenter ayrıca bir düğmeye basma, gezinme vb. Hareketler için mantık da içerecektir.

  • Pro: Veri tabanını kaldırarak kod miktarını azaltır.
  • Con: daha az test edilebilir bir yüzey var (veri bağlama nedeniyle) ve doğrudan Modelle konuştuğundan beri Görünümde daha az kapsülleme var.

Model-View-Controller

MVC 'de, Denetleyici, uygulama yüklendiğinde de dahil olmak üzere herhangi bir eyleme yanıt olarak hangi Görünümün görüntüleneceğini belirlemekten sorumludur. Bu, eylemlerin Görünüm üzerinden Sunucuyu yönlendirdiği MVP'den farklıdır. MVC'de, Görünümdeki her eylem, bir eylemle birlikte bir Denetleyiciye yapılan çağrıyla ilişkilendirilir. Web'de her bir eylem, diğer tarafında yanıt veren bir Denetleyicinin bulunduğu bir URL'ye yapılan çağrıyı içerir. Bu Kontrolör işlemlerini tamamladıktan sonra, doğru Görüntüye geri dönecektir. Sıralama, uygulamanın ömrü boyunca bu şekilde devam eder:

 
    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

MVC ile ilgili diğer bir büyük fark da, Görünümün doğrudan Modele bağlı olmamasıdır. Görünüm basitçe işliyor ve tamamen vatansız. MVC uygulamalarında, Görünüm genellikle arkasındaki kodda herhangi bir mantığa sahip olmayacaktır. Bu kesinlikle gerekli olduğu MVP'ye aykırıdır, çünkü Görünüm Sunucuyu devredemezse, asla çağrılmaz.

Sunum Modeli

Bakılması gereken diğer bir desen Sunum Modeli desenidir. Bu düzende Presenter yoktur. Bunun yerine Görünüm doğrudan bir Sunum Modeline bağlanır. Sunum Modeli, Görünüm için özel olarak hazırlanmış bir Modeldir. Bu, bu Modelin kaygıların ayrılmasının ihlali olacağı için asla bir etki alanı modeline koyamayacağı özellikleri ortaya çıkarabileceği anlamına gelir. Bu durumda, Sunum Modeli etki alanı modeline bağlanır ve bu Modelden gelen olaylara abone olabilir. View daha sonra Sunum Modelinden gelen olaylara abone olur ve buna göre kendini günceller. Sunu Modeli, görünümün eylemleri çağırmak için kullandığı komutları gösterebilir. Bu yaklaşımın avantajı, PM'in görünüm için tüm davranışları tamamen içine almasından dolayı, esasen tamamen arka plandaki kodu kaldırabilmenizdir. Bu kalıp WPF uygulamalarında kullanım için çok güçlü bir adaydır ve ayrıca Model-View olarak adlandırılır. -ViewModel .

Bir Sunu Modeli hakkında MSDN makalesi ve bir bölüm var WPF için Kompozit Uygulama Kılavuzu 'nda (eski Prizma) = "http://msdn.microsoft.com/en-us/library/cc707862.aspx" rel = "noreferrer"> Ayrılmış Sunum Kalıpları

    
1915
2017-12-03 23: 01: 14Z
  1. Lütfen bu cümleyi açıklayabilir misiniz? Bu, eylemlerin Görünümden Sunucuyu yönlendirdiği MVP'den farklıdır. MVC’de, Görünüm’deki her eylem, bir eylemciyle birlikte bir Denetleyiciye yapılan bir çağrıyla ilişkilidir. Bana göre, aynı şey gibi görünüyor, ancak eminim farklı bir şey tanımlıyorsunuzdur.
    2016-10-19 13: 24: 23Z
  2. @ Panzercrisis Yazarın ne anlama geldiğinden emin değilim, ama söylemeye çalıştıklarını sanıyorum. Bu yanıt gibi - stackoverflow.com/a/2068/74556 , MVC'de denetleyici yöntemlerinin davranışlara dayandığını belirtmektedir - Başka bir deyişle, tek bir denetleyiciye birden fazla görünüm (ancak aynı davranış) eşleyebilirsiniz. MVP'de, sunum yapan kişi görünüme daha yakın bir şekilde birleştirilmiştir ve genellikle bire bir yakın bir haritalama ile sonuçlanır, yani bir görünüm hareketi ilgili sunumcunun yöntemine eşlenir. Genellikle başka bir görünümün eylemlerini başka bir sunum yapan kişinin (başka bir görünümden) yöntemiyle eşlemezsiniz.
    2016-10-28 17:50:43Z

Bu, bu tasarım modellerinin bir çok değişkeninin aşırı basitleştirilmesidir, ancak bu, ikisi arasındaki farklılıklar hakkında düşünmeyi seviyorum.

VC

MVC

MVP

resim tanımını buraya girin

    
414
2013-07-06 22: 18: 01Z
  1. Bu, sunumcunun API'sinden GUI ile ilgili (soyutlama öğelerinin) soyutlanmasını ve tümüyle izolasyonunu gösteren şematik bir tasviridir. Küçücük bir nokta: Bir ana sunum, görüntüleme başına bir değil, yalnızca bir sunum yapan yerlerde kullanılabilir, ancak diyagramınız en temiz olandır. IMO, MVC /MVP arasındaki en büyük fark, MVP'nin görünümü, mevcut 'görüntüleme durumunun' görüntülenmesinden başka bir şeyden tamamen boş tutmaya çalışması (aynı zamanda veriyi görmek) ve Model nesnelerin bilgisine olan görüşü engellemektir. Böylece, orada olması gereken arayüzler, bu durumu enjekte etmek için.
    2013-10-15 03: 30: 50Z
  2. İyi resim. Çok fazla MVP kullanıyorum, bu yüzden bir noktaya değinmek istiyorum. Tecrübelerime göre, Sunum yapanların birbirleriyle oldukça sık konuşması gerekir. Aynı model (veya iş nesneleri) için de geçerlidir. MVP resminizde olacak olan bu ek "mavi çizgiler" nedeniyle, Presenter-Model ilişkileri oldukça karışık olabilir. Bu nedenle, bire bir çok kişiye karşı bire bir Presenter-Model ilişkisi sürdürme eğilimindeyim. Evet, Model için bazı delege yöntemleri gerektirir, ancak Model'in API'sinin yenilenmesi gerekiyorsa veya değişmesi durumunda birçok baş ağrısını azaltır.
    2014-02-28 14: 45: 43Z
  3. MVC örneği yanlıştır; Görüşlerle denetleyiciler arasında sıkı bir 1: 1 ilişki var. Tanım olarak, bir denetleyici, model için olaylar üretmek ve aynı şekilde tek bir kontrol için görünüm oluşturmak için insan hareketi girişini yorumlar. Daha basit olarak, MVC'nin sadece bireysel widget'larla kullanılması amaçlanmıştır. Bir widget, bir görünüm, bir kontrol.
    2014-04-05 15: 34: 06Z
  4. @ SamuelA.FalvoII her zaman değil, 1: ASP.NET MVC'deki denetleyiciler ve görünümler arasında çoğu: stackoverflow.com/sorular /1673301 /...
    2016-01-07 17: 57: 27Z
  5. @ StuperUser - Bunu yazarken ne düşündüğümden emin değilim. Tabii ki haklısın ve yazdıklarımın arkasına bakarak, dile getiremediğim başka bir bağlamım olup olmadığını merak etmeliyim. Düzeltme için teşekkürler.
    2016-01-11 23: 40: 31Z

Bunu bir süre önce blogladım, Todd Snyder'in ikisi arasındaki farkla ilgili mükemmel yayını :

  

İşte arasındaki temel farklar   kalıplar:

     

MVP Şablonu

     
  • Görünüm, modele daha gevşek bir şekilde bağlı. Sunucu   modeli bağlamaktan sorumlu   görünüm.
  •   
  • Ünite testi daha kolaydır, çünkü görünümle etkileşim geçer   bir arayüz
  •   
  • Genellikle sunum yapan haritayı bire bir görüntüler. Karmaşık manzaralar olabilir   çoklu sunumlar.
  •   

MVC Deseni

     
  • Denetleyici davranışlara dayanır ve bunlar arasında paylaşılabilir   görünümler
  •   
  • Hangi görünümün görüntüleneceğini belirlemekten sorumlu olabilir
  •   

Bulabildiğim web üzerindeki en iyi açıklama.

    
405
2015-05-04 03: 28: 06Z
  1. Görünüşe göre, her iki durumda da tümüyle onları tamamen ayırmak için görünümün modele nasıl daha da az bağlanabileceğini anlamıyorum. Yanlış bir şey söylediğini kastetmiyorum - sadece ne demek istediğini kafam karıştı.
    2011-10-05 00: 25: 40Z
  2. @ pst: MVP ile birlikte gerçekten 1 View = 1 Presenter. MVC ile, Denetleyici çoklu görünümleri yönetebilir. İşte bu, gerçekten. "Sekmeler" modelinde, her sekmenin tüm sekmeler için bir Denetleyiciye sahip olmanın aksine kendi Presenter'a sahip olduğunu hayal edin.
    2012-06-29 09: 46: 41Z
  3. Aslen iki tür denetleyici vardır: birden çok görünümde paylaşıldığını söylediğiniz ve özellikle de arayüzün arayüzünü uyarlamak isteyen belirli görünümler paylaşılan denetleyici.
    2013-11-11 14: 12: 24Z
  4. @ JonLimjap Yine de bir bakış açısıyla ne anlama geliyor? İOS programlama bağlamında tek ekranlı mı? Bu, iOS denetleyicisini MVC'ye göre MVP'ye benzetiyor mu? (Öte yandan, ekran başına birden fazla iOS denetleyiciniz de olabilir)
    2014-03-19 07: 55: 12Z
  5. Well Todd'un MVC'nin diyagramatik gösterimi, Görünüm ve Modeli ayrıştırma fikrine tamamen aykırı. Diyagrama bakarsanız, Model güncellemeleri View (Model'den View'a ok) yazmaktadır. Hangi evrenin bir sistem olduğu, Modelin Görünümle doğrudan etkileşime girdiği, ayrık bir sistem ???
    2017-06-04 02: 01: 35Z

İşte iletişim akışını temsil eden resimler.

buraya görüntü açıklamasını girin

 Resim tanımlamasını buraya girin

    
239
2014-09-12 20: 47: 56Z
  1. MVC diyagramı ile ilgili bir sorum var. Görünümün veri toplamaya gittiği kısmı anlamadım. Denetleyicinin gereken verileri içeren görüntüye yönlendireceğini düşünüyorum.
    2015-05-12 21: 07: 21Z
  2. Bir kullanıcı bir düğmeyi tıklarsa, görünümle etkileşime girmeyen durum nedir? MVC'de hissediyorum, kullanıcı görünümle denetleyiciden daha fazla etkileşime giriyor
    2015-08-12 03: 28: 10Z
  3. Bunun eski bir cevap olduğunu biliyorum - ama @JonathanLeaders noktasında herhangi biri yanıt verebilir mi? Çok özel bir kodlama yapmadığınız sürece winforms arkaplanından geliyorum, UI /View tıklattığınızda herhangi bir şeyden önce bu tıklamayı öğreniyor. En azından bildiğim kadarıyla?
    2016-01-04 14: 44: 33Z
  4. @ RobP. Bence bu tür grafikler her zaman çok karmaşık veya çok basit olma eğilimindedir. MVP grafiğinin akışı aynı zamanda bir MVC uygulaması için de geçerlidir. Dillerin özelliklerine bağlı olarak farklılıklar olabilir (veri bağlama /gözlemci), ancak sonuçta görüş, uygulamanın verisinden /mantığından görünümü ayırmaktır.
    2016-01-17 09: 37: 06Z
  5. @ JonathanLeaders İnsanlar "MVC" deyince aklında gerçekten farklı şeyler var. Bu çizelgeyi oluşturan kişi muhtemelen klasik Web MVC'sine sahipti, burada "kullanıcı girişi" HTTP istekleridir ve "görünüm kullanıcıya geri döndü" işlenmiş bir HTML sayfasıdır. Bu nedenle, bir kullanıcı ile görünüm arasındaki herhangi bir etkileşim, klasik Web MVC uygulaması yazarı açısından "mevcut değildir".
    2016-06-12 14: 38: 00Z

MVP, değildir mutlaka Görünümün sorumlu olduğu bir senaryodur (örneğin, Taligent'in MVP'sine bakınız).
İnsanların, "Bu sadece bir manzara" (Pragmatik Programcı) ile çelişen bir karşıtlık modelinin aksine, bunu bir kalıp olarak (sorumlu bakış açısı) vaaz ettiğini talihsiz buluyorum. "Bu sadece bir görünüm", kullanıcıya gösterilen son görüşün uygulamanın ikincil bir endişesi olduğunu belirtir. Microsoft'un MVP modeli, Görünümlerin yeniden kullanımını çok daha zorlaştırıyor ve rahatça Microsoft'un tasarımcısını kötü uygulamaları teşvik etmekten alıkoyuyor.

Tamamen açık olmak gerekirse, MVC'nin altında yatan endişelerin herhangi bir MVP uygulaması için geçerli olduğunu ve farklılıkların neredeyse tamamen anlamsal olduğunu düşünüyorum. Görünüm (verileri görüntüleyen), denetleyici (kullanıcı etkileşimini başlatan ve kontrol eden) ve model (temel veri ve /veya hizmetler) arasındaki endişelerin ayrılmasını takip ettiğiniz sürece, MVC'nin avantajlarını elde etmiş olursunuz. . Avantajları elde ediyorsanız, modelinizin MVC, MVP veya Denetleyici Denetleyici olup olmadığını gerçekten kim umursar? Yalnızca gerçek kalıp MVC olarak kalır, gerisi sadece farklı tatlardır.

Kapsamlı bir şekilde listeleyen çok heyecan verici bir makaleyi bu dikkate alın. bu farklı uygulamaların sayısı. Hepsinin temelde aynı şeyi ancak biraz farklı şekilde yaptıklarını not edebilirsiniz.

Şahsen, MVP'nin yakın zamanda, bir şeyin gerçekten MVC olup olmadığını ya da Microsofts Hızlı Uygulama Geliştirme araçlarını haklı çıkarmak ya da haklı çıkarmak için olan anlamsal bigots arasındaki argümanları azaltmak için akılda kalıcı bir terim olarak yeniden tanıtıldığını düşünüyorum. Kitaplarımdaki bu sebeplerin hiçbiri varlığını ayrı bir tasarım deseni olarak haklı çıkarmaz.

    
161
2019-01-04 11: 40: 38Z
  1. MVC /MVP /MVVM /etc 'arasındaki farklar hakkında birkaç cevap ve blog okudum. Aslında, işiniz bittiğinde, hepsi aynı. Arayüzünüz olup olmadığı ve bir belirleyici (veya başka bir dil özelliği) kullanıp kullanmadığınız önemli değildir. Bu kalıplar arasındaki farkın, bir kavram meselesi yerine, çeşitli çerçevelerin uygulamalarındaki farktan doğduğu anlaşılmaktadır.
    2011-03-07 22: 36: 15Z
  2. MVP'ye anti-desen demedim, sonraki yazıda olduğu gibi ".. the rest [MVP dahil] tamamen farklı [MVC] 'nin lezzetleri ", eğer MVP bir anti-patern ise, MVC'nin ... farklı bir çerçevenin yaklaşımı için sadece bir lezzet olduğu anlamına gelir. (Şimdi, bazı belirli MVP uygulamaları, farklı görevler için bazı belirli MVC uygulamalarından daha fazla ya da daha az istenebilir ...)
    2012-06-15 19: 31: 27Z
  3. @ Quibblsome: “Bence kişisel olarak MVP'nin yakın zamanda, bir şeyin gerçekten MVC olup olmadığını iddia eden semantik bigotlar arasındaki argümanları azaltmak için çekici bir terim olarak tanıtıldığını düşünüyorum […] Kitaplarımdaki bu sebeplerin hiçbiri varlığını ayrı bir tasarım deseni olarak haklı göstermiyor. ” Bunu ayırt etmek için yeterince farklı. MVP'de görünüm, önceden tanımlanmış bir arayüzü karşılayan herhangi bir şey olabilir (MVP'deki Görünüm bağımsız bir bileşendir). MVC'de, Kontrolör belirli bir görüş için üretilir (ilişkinin ariteleri birisinin başka bir terime değdiğini hissettirebilirse).
    2013-02-20 15: 50: 21Z
  4. @ Hibou57, MVC'nin görüntüyü bir arabirim olarak göstermesini ya da birkaç farklı görünüm için genel bir denetleyici oluşturmasını durduracak hiçbir şey yok.
    2013-02-22 16: 34: 06Z
  5. Samuel, lütfen neden bahsettiğinizi açıklığa kavuşturun. Bana MVC'yi "icat eden" takımın tarihini söylemiyorsanız, o zaman metniniz için inanılmaz derecede şüpheliyim. Eğer sadece WinForm hakkında konuşuyorsanız, başka şeyler yapmanın başka yolları da var ve kontrol bağlantılarının "bireysel kontroller" tarafından değil kontrol cihazı tarafından yönetildiği WinForm projeleri yarattım.
    2014-04-07 12: 44: 40Z

MVP: görünüm sorumlu.

Görünüm, çoğu durumda sunucusunu oluşturur. Sunucu modelle etkileşime girecek ve görünümü bir arayüz üzerinden değiştirecektir. Görünüm bazen sunum yapan ile etkileşime girer, genellikle bazı arayüzlerle. Bu uygulamaya geçiyor; görünümün sunucudaki yöntemleri çağırmasını mı yoksa görünümün sunucunun dinleyeceği olayları olmasını mı istiyorsunuz? Bu aşağı kaynar: Görünüm sunucu hakkında biliyor. Görünüm, sunum yapan kişiye sunum yapar.

MVC: denetleyici yetkili.

Denetleyici, bazı olay /isteklere göre oluşturulur veya erişilir. Denetleyici daha sonra uygun görünümü oluşturur ve görünümü daha fazla yapılandırmak için modelle etkileşime girer. Aşağı kaynar: denetleyici görünümü oluşturur ve yönetir; görünüm kontrolöre bağımlıdır. Görünüm denetleyiciyi bilmiyor.

    
104
2015-05-04 03: 31: 41Z
  1. "Görünüm Denetleyici hakkında bir şey bilmiyor." Sanırım bu görüşün modelle doğrudan teması yok mu?
    2010-03-25 07: 51: 20Z
  2. görünüm, eiether'deki model hakkında hiçbir zaman bilgi sahibi olmamalıdır.
    2010-03-29 19: 03: 04Z
  3. @ Brian: “Görünüm, çoğu durumda Sunucusunu oluşturur.”. Çoğunlukla bunun tam tersini gördüm, Presenter hem Model hem de Görünümü başlattı. Peki, Görünüm de Sunucuyu başlatabilir, ancak bu nokta gerçekten en belirgin değil. En önemli olan şey, ömür boyu daha sonra gerçekleşmesidir.
    2013-02-20 15: 55: 38Z
  4. Daha fazla açıklamak için cevabınızı düzenlemek isteyebilirsiniz: Görünüm Denetleyici hakkında bilgi sahibi olmadığından, 'görsel' öğeler üzerinde gerçekleştirilen kullanıcı eylemleri nasıldır? kullanıcı Denetleyiciye iletilen ekranı görür (yani Görünüm) ...
    2017-06-05 05: 21: 54Z

girin resim açıklaması burada

MVC (Model Görünüm Kontrolörü)

Giriş, görünüm yerine ilk önce Denetleyiciye yönlendirilir. Bu giriş, bir sayfa ile etkileşime giren bir kullanıcıdan geliyor olabilir, ancak yalnızca bir tarayıcıya belirli bir URL girerek de olabilir. Her iki durumda da, bazı işlevselliklere başlamak için ara yüzleştiği bir Denetleyici. Denetleyici ile Görünüm arasında birebir ilişki vardır. Bunun nedeni, tek bir kontrol cihazının yürütülen işleme göre oluşturulacak farklı görünümler seçebilmesidir. Denetleyiciden Görünüme giden tek yönlü oku not edin. Bunun nedeni, Görünümün denetleyiciyle ilgili hiçbir bilgisi veya referansı olmamasıdır. Kontrolör Modeli geri atar, bu nedenle Görünüm ve kendisine verilen beklenen Model arasında bilgi vardır, ancak hizmet veren Kontrolör değil.

MVP (Model Görünümü Sunucusu)

Giriş, Sunucu ile değil, Görünüm ile başlar. Görünüm ile ilişkili Presenter arasında bire bir eşleme var. Görünüm, Sunucuya bir referans tutar. Presenter ayrıca Görünümden tetiklenen olaylara da tepki veriyor, bu nedenle onunla ilişkili Görünümün farkında. Sunucu, Model üzerinde gerçekleştirdiği istenen eylemlere dayanarak Görünümü günceller, ancak Görünüm Model farkında değildir.

Daha fazla bilgi için Referans

    
72
2015-12-20 02: 10: 22Z
  1. Ancak, uygulama ilk kez yüklendiğinde MVP biçiminde, sunum yapan kişi ilk görünümü yüklemekle yükümlü değil midir? Mesela facebook başvurusunu yüklediğimizdegiriş sayfasını yükleyebilir mi?
    2016-11-11 05: 18: 05Z
  2. Modelden MVC'ye Görüntülenecek bir bağlantı mı? Cevabınızı, bu bağlantı verilen, bunun nasıl 'ayrık' bir sistem yaptığını açıklamak için düzenlemek isteyebilirsiniz. İpucu: Zor bulabilirsin. Ayrıca, okuyucunun tüm yaşamları boyunca yanlış hesapladıklarını mutlu bir şekilde kabul edeceğini düşünmüyorsanız, kullanıcının ekrandaki 'görsel' öğelerle etkileşime girmesine rağmen, MVC'deki Denetleyici'den önce neden işlemlerin geçtiğini açıklamak isteyebilirsiniz. Görünüm), işlem yapmanın arkasında oturan bazı soyut katmanları değil.
    2017-06-05 02: 32: 51Z
  3. Bu açıkça yanlıştır ... MVC'de, model hiçbir zaman doğrudan görünümle ve tam tersiyle konuşmaz. Başka birinin var olduğunu bile bilmiyorlar. Kontrolör onları bir arada tutan yapıştırıcıdır
    2018-10-25 12: 39: 36Z
  4. Ash ve MegaManX ile aynı fikirdeyim. MVC diyagramında, ok Modelden Görünüme değil, Model'e işaret eden Görünümden (veya ViewModel veya DTO) olmalıdır; Çünkü Model Görünüm hakkında bir şey bilmiyor ama görünüm Model hakkında bilgi sahibi olabilir.
    2019-04-10 06: 45: 39Z

Sorunun birçok yanıtı var, ancak ikisini açıkça karşılaştıran bazı gerçekten basit cevaplara ihtiyaç duyulduğunu hissettim. İşte, bir kullanıcı bir MVP ve MVC uygulamasında bir film adı aradığında yaptığım tartışma:

Kullanıcı: Tıkla…

Görüntüle : Kim o? [ MVP | MVC ]

Kullanıcı: Sadece arama düğmesini tıkladım…

Görüntüle : Tamam, bir saniye bekleyin…. [ MVP | MVC ]

( Görüntüle Sunucuyu | Denetleyiciyi … çağırıyor…) [ MVP | MVC ]

Görüntüle : Hey Sunucu | Denetleyici , bir kullanıcı arama düğmesini tıklattı, ne yapmalıyım? [ MVP | MVC ]

Sunucu | Denetleyici : Hey Görüntüle , o sayfada herhangi bir arama terimi var mı? [ MVP | MVC ]

Görüntüle : Evet,… işte burada… “piyano” [ MVP | MVC ]

Sunucu : Teşekkürler Görüntüle ,… bu arada Model 'de arama terimine bakıyorum, lütfen ona bir ilerleme gösterin bar [ MVP | MVC ]

( Sunucu | Denetleyici Model … 'i çağırıyor) [ MVP | MVC üçlü>]

Sunucu | Denetleyici : Hey Model , Bu arama terimi için herhangi bir eşleşmeniz var mı ?: “piyano” [ MVP | MVC ]

Model : Hey Sunucu | Denetleyici , kontrol edeyim… [ MVP | MVC ]

( Model , film veritabanına sorgu yapıyor…) [ MVP | MVC ]

(Bir süre sonra ...)

-------------- Bu, MVP ve MVC'nin ayrılmaya başladığı yer ---------------

Model : Sizin için bir liste buldum Sunucu , işte burada JSON “[{" name ”:" Piyano Öğretmeni "," yıl ": 2001 }, {"name": "Piyano", "yıl": 1993}] "[ MVP ]

Model : Bazı sonuçlar var, Denetleyici . Benim örneğimde bir alan değişkeni yarattım ve sonucu ile doldurdum. Adı "searchResultsList" [ MVC ]

( Sunucu | Denetleyici teşekkürler Model ve Görünüm 'e geri döner)) [ MVP | MVC ]

Sunucu : Beklediğiniz için teşekkürler Görüntüle , eşleşen sonuçların bir listesini buldum ve sunulabilir bir biçimde ayarladım: ["Piano Teacher 2001", "Piano 1993" ]. Lütfen bunu kullanıcıya dikey listede gösterin. Ayrıca lütfen ilerleme çubuğunu şimdi gizleyin [ MVP ]

Denetleyici : Beklediğiniz için teşekkürler Görüntüle , arama sorgunuz hakkında Model sordum. Eşleşen sonuçların bir listesini bulduğunu ve bunları örneğinin içinde "searchResultsList" adlı bir değişkende sakladığını söylüyor. Oradan alabilirsin. Ayrıca lütfen ilerleme çubuğunu şimdi gizleyin [ MVC ]

Görüntüle : Çok teşekkür ederim Sunucu [ MVP ]

Görüntüle : Teşekkürler "Denetleyici" [ MVC ] (Şimdi Görünüm görevdirİyonlaşma: Model 'den aldığım sonuçları kullanıcıya nasıl sunmalıyım? Filmin prodüksiyon yılı ilk mi yoksa son mu olmalı? Yatay mı dikey mi olmalı? ...)

İlgilendiğiniz takdirde, bir Github repo eşliğinde uygulama mimari kalıpları (MVC, MVP, MVVP, temiz mimari, ...) ile ilgili bir dizi makale yazıyorum. burada . Örnek android için yazılmış olsa da, temel prensipler herhangi bir ortama uygulanabilir.

    
44
2018-04-06 13: 51: 19Z
  1. Temel olarak söylemeye çalıştığınız şey, denetleyicinin görünüm mantığını yönettiğidir. Bu yüzden, ne olduğunu ve nasıl göründüğünü sunarak görünümü engelliyor mu?
    2018-08-28 14: 37: 18Z
  2. @ Radu, Hayır, mikro yönetme yapmaz, sunum yapan kişinin görünümü pasif veya dilsiz hale getirerek yaptığı şeydir
    2018-08-28 22: 48: 04Z
  3. Uygun bir MVC'de görünüm, denetleyicide işlevsellik çağırır ve modeldeki veri değişikliklerini dinler. Görünüm denetleyiciden veri alamıyor ve denetleyici görünüme, örneğin bir yükleme göstergesini göstermesini söylememelidir. Uygun bir MVC, görünüm kısmını temelde farklı olanlarla değiştirmenize olanak sağlar. Görünüm kısmı, bir yükleme göstergesi içeren görünüm mantığına sahiptir. Görünüm, komutları (denetleyicide) çağırır, denetleyici modeldeki verileri değiştirir ve model, verilerindeki değişiklikleri dinleyicilere bildirir, böyle bir dinleyici de görünümdür.
    2018-10-22 12: 50: 11Z
  • MVP = Model-Görünüm Sunucusu
  • MVC = Model Görünümü Denetleyici

    1. Her iki sunum düzeni. Bir Model (alan nesnelerini düşünün), ekranınız /web sayfanız (Görünüm) ve kullanıcı arayüzünüzün nasıl davranması gerektiği (Sunucu /Denetleyici) arasındaki bağımlılıkları ayırırlar
    2. Konsept açısından oldukça benzerler, millet, Presenter /Controller'ı zevkinize bağlı olarak farklı şekilde başlatıyor.
    3. Farklılıklar üzerine harika bir makale burada . En kayda değer, MVC modelinin Görünümü güncelleyen Modeline sahip olmasıdır.
34
2013-04-20 09: 17: 51Z
  1. VIew'i güncelleyen model. Ve bu hala ayrık bir sistem mi?
    2017-06-05 02: 33: 59Z

Ayrıca hatırlamaya değer, farklı tipteki MVP'lerin de olduğu. Fowler kalıbı ikiye böldü - Pasif Görüntü ve Denetleyici Denetleyici.

Pasif Görünüm kullanırken, Görünümünüz tipik olarak altta yatan UI widget'ına doğrudan veya daha az veya daha çok eşlenen özellikler içeren ince taneli bir arabirim uygular. Örneğin, Ad ve Adres gibi özelliklere sahip bir ICustomerView'e sahip olabilirsiniz.

Uygulamanız şöyle bir şeye benzeyebilir:

 
public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Presenter sınıfınız modelle konuşacak ve görünüme "eşleyecektir". Bu yaklaşıma "Pasif Bakış" denir. Avantaj, görünümün test edilmesinin kolay olması ve UI platformları arasında gezinmenin (Web, Windows /XAML, vb.) Daha kolay olmasıdır. Dezavantajı, veri bağlama gibi şeylerden yararlanamamanızdır ( gerçekten WPF ve Silverlight ).

MVP'nin ikinci lezzeti Denetleyici Denetleyici'dir. Bu durumda, Görünümünüzün Müşteri adı altında bir mülkiyeti olabilir ve bu durumda yine UI araç gereçlerine veri bağlanır. Senkronizasyon hakkında düşünmeniz gerekmez veIcro-yönetimi, ve denetleyici denetleyicisi, örneğin tamamlanmış etkileşim mantığı ile, gerektiğinde devreye girebilir ve yardımcı olabilir.

MVP’nin üçüncü “tadı” (veya biri belki de ayrı bir desen olarak adlandırılır) Sunum Modeli'dir (veya bazen Model-View-ViewModel’e atıfta bulunulabilir). MVP'ye kıyasla, M ve P'yi bir sınıfta "birleştirirsiniz". UI widget'larınızın verinin bağlı olduğu müşteri nesneniz var, ancak "IsButtonEnabled" veya "IsReadOnly", vb. Gibi ek UI'ye özgü alanlar da var

UI mimarisine bulduğum en iyi kaynağın, Jeremy Miller tarafından Kendi CAB Dizini Yarat İçindekiler . MVP'nin tüm lezzetlerini yaptı ve uygulamak için C # kodu gösterdi.

YouCard Yeniden Ziyaret Edildi: ViewModel desenini uygulama .

    
33
2015-05-04 03: 34: 56Z

Model-View-Controller

MVC bir yazılım uygulamasının mimarisi için bir kalıptır. Uygulama mantığını modülerliği ve işbirliği ve yeniden kullanım kolaylığı ile üç ayrı bölüme ayırır. Ayrıca uygulamaları daha esnek hale getirir ve yinelemelere karşı hoş geldiniz. Bir uygulamayı aşağıdaki bileşenlere ayırır:

  • Verileri ve işletme mantığını işlemek için modeller
  • Kullanıcı arayüzünü ve uygulamayı idare etmek için Kontrolörler
  • Grafik kullanıcı arabirimi nesnelerini ve sunumunu işlemek için görünümler

Bunu biraz daha net hale getirmek için, basit bir alışveriş listesi uygulamasını düşünelim. Tek istediğimiz, bu hafta satın almamız gereken her öğenin adı, miktarı ve fiyatının bir listesi. Aşağıda, bu işlevselliğin bazılarını MVC kullanarak nasıl uygulayabileceğimizi açıklayacağız.

 buraya resim açıklamasını girin

Model-View-Presenter

  • Model , görünümde görüntülenecek verilerdir (kullanıcı arayüzü).
  • Görünüm , verileri görüntüleyen (model) ve kullanıcı komutlarını (olayları) bu verilere göre davranması için Sunucuya yönlendiren bir arabirimdir. Görünüm genellikle Sunucusuna atıfta bulunur.
  • Sunucu , “orta erkektir” (MVC'de denetleyici tarafından oynatılır) ve hem görünüm hem de model referansları vardır. Lütfen "Model" kelimesinin yanıltıcı olduğunu unutmayın. Bunun yerine, bir Modeli alan veya değiştiren iş mantığı olmalı . Örneğin: Kullanıcıyı bir veritabanı tablosunda saklayan bir veritabanınız varsa ve Görünümünüz bir kullanıcı listesi görüntülemek isterse, Sunum Yapan Sunucunun bir listeyi sorgulayacağı yerden veritabanı iş mantığınıza (DAO gibi) bir referansı olacaktır. Kullanıcıların.
  

Basit uygulamalı bir örnek görmek istiyorsanız lütfen kontrol edin.    bu GitHub yayını

Bir veritabanından kullanıcıların listesini sorgulama ve görüntüleme konusunda somut bir iş akışı şöyle olabilir: buraya resim açıklamasını girin

  

MVC ve MVP kalıpları arasındaki fark nedir?

MVC Deseni

  • Denetleyici davranışlara dayanır ve görünümler arasında paylaşılabilir

  • Hangi görünümün görüntüleneceğini belirlemekten sorumlu olabilir (Ön Kontrol Şablonu)

MVP Şablonu

  • Görünüm, modele daha gevşek bir şekilde bağlı. Sunucuyu modeli görünüme bağlamaktan sorumludur.

  • Görünümle etkileşim bir arabirimden geçtiğinden ünite testi daha kolay çünkü

  • Genellikle sunum yapan haritayı bire bir görüntüler. Karmaşık görünümlerde birden fazla sunucu olabilir.

24
2019-06-13 07: 38: 06Z
  1. nah, mvc'deki görünüm ile model arasında doğrudan bağlantı yoktur. Diyagramın yanlış.
    2019-06-01 15: 21: 42Z

Her biri farklı sorunlara yöneliktir ve aşağıdakine benzer şeyler olması için bir araya getirilebilirler bile

Kombine Desen

Ayrıca MVC, MVP ve MVVM’nin tam karşılaştırması burada

    
20
2017-03-13 05: 54: 59Z

Bu çerçevelerin her ikisi de endişeleri ayrı tutmayı amaçlamaktadır - örneğin, bir veri kaynağı (model) ile etkileşim, uygulama mantığı (veya bu verileri yararlı bilgilere dönüştürmek) (Denetleyici /Sunucu) ve ekran kodu (Görünüm). Bazı durumlarda model, bir veri kaynağını daha yüksek bir soyutlamaya dönüştürmek için de kullanılabilir. Buna güzel bir örnek MVC Storefront projesidir .

Bir tartışma var burada .

Yapılan ayrım, bir MVC uygulamasında geleneksel olarak görüş ve denetleyicinin modelle etkileşime girmesidir ancak birbirleriyle değil.

MVP tasarımları Presenter'ın modele erişmesini ve görünümle etkileşime girmesini sağlar.

ASP.NET MVC'nin bu tanımlara göre bir MVP çerçevesi olduğunu söylemiştik, çünkü Kontrolör, Model'e mantığı olmayan (sadece Kontrolör tarafından sağlanan değişkenleri gösterir) göstermek için Modele erişir.

MVP'den ASP.NET MVC ayrımı hakkında bir fikir edinmek için bu MIX sunumunu inceleyin. Scott Hanselman tarafından.

    
18
2008-08-05 10: 24: 58Z
  1. MVC ve MVP çerçeveler değil kalıplardır. Dürüstçe, bu konunun .NET framework ile ilgili olduğunu düşünüyorsanız, "internet" i duymak ve IE hakkında olduğunu düşünmek gibidir.
    2012-06-18 17: 26: 32Z
  2. Sorunun, 2008’de ilk kez tekrar sorulduğunda önemli ölçüde geliştiğinden eminim. Ayrıca, cevabımı tekrar inceliyorum (ve bu 4 yıl önceydi, bu yüzden yapmadım) senden çok daha fazla bağlam) Genel olarak başladığımı ve ardından .NET MVC'yi somut bir örnek olarak kullandığımı söyleyebilirim.
    2012-06-19 05: 08: 20Z

Her ikisi de sunum ve iş mantığını ayırmaya çalışan, iş mantığını UI yönünden ayırmaya çalışan modellerdir

Mimari olarak, MVP, MVC'nin Ön Kontrolör tabanlı bir yaklaşım olduğu Sayfa Denetleyicisi tabanlı bir yaklaşımdır. Bu, MVP standart web formunda sayfa yaşam döngüsünün sadece iş mantığını arkadaki koddan ayıklayarak arttırıldığı anlamına gelir. Diğer bir deyişle, sayfa bir http hizmetini vermektir. Başka bir deyişle, MVP IMHO evrimsel bir gelişme türü olan web formudur. Diğer taraftan MVC, oyunu tamamen değiştirir, çünkü istek yüklenmeden önce denetleyici sınıfı tarafından ele geçirilir, iş mantığı orada yürütülür ve daha sonra sayfaya atanan verileri işleyen denetleyicinin sonunda ("görünüm") Bu anlamda, MVC (en azından benim için) yönlendirme motoruyla geliştirilmiş MVP'nin Denetleyici lezzetini denetlemeye çok benziyor.

Her ikisi de TDD'yi etkinleştirir ve olumsuz ve olumsuz yönlere sahiptir.

Bunlardan birinin nasıl seçileceğine dair karar IMHO, bir ASP NET web formu web geliştirme türü için ne kadar zaman harcandığına dayanmalıdır. Eğer biri web formunda kendini iyi görse, MVP'yi öneririm. Eğer biri o kadar rahat hissetmezsesayfa yaşam döngüsü, vb. gibi şeylerde ble. MVC buraya gitmek için bir yol olabilir.

Bu konuyla ilgili biraz daha ayrıntılı bilgi veren başka bir blog yazısı bağlantısı daha var

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

    
13
2008-09-22 07: 07: 21Z

Hem MVP'yi hem de MVC'yi kullandım ve geliştiriciler olarak her iki modelin teknik farklılıklarına odaklanma eğiliminde olsak da, IMHO'daki MVP'nin amacı, her şeyden çok, benimseme kolaylığı ile ilgilidir.

Zaten web üzerinde iyi bir geçmişe sahip bir ekipte çalışıyorsam, geliştirme stili, MVP'yi tanıtmak MVC'den çok daha kolaydır. Bu senaryoda MVP'nin hızlı bir kazanç olduğunu söyleyebilirim.

Deneyimlerim bana bir ekibi web formlarından MVP'ye ve ardından MVP'den MVC'ye taşımanın nispeten kolay olduğunu söylüyor; web formlarından MVC'ye geçmek daha zor.

Bir arkadaşımın MVP ve MVC hakkında yayınladığı bir dizi makalenin bağlantısını burada bırakıyorum.

http://www.qsoft.be/posta /Yapı-MVP-StoreFront-Gutthrie-style.aspx

    
9
2009-01-02 10: 35: 25Z

MVP'de görünüm, modelden veri çeken ve hazırlayan /normalize eden sunum yapan kişiden veri alırken, MVC'de denetleyici görünümden iterek modelden veri alır ve ayarlanır.

MVP’de, birden çok sunum türüyle çalışan tek bir görünüme ve farklı çoklu görünümlerle çalışan tek bir sunuma sahip olabilirsiniz.

MVP genellikle Microsoft WPF ciltleme çerçevesi veya HTML5 ve Java için çeşitli ciltleme çerçeveleri gibi bir tür ciltleme çerçevesi kullanır.

Bu çerçevelerde, UI /HTML5 /XAML, her UI öğesinin sunumcunun hangi özelliğinin görüntülendiğinin farkındadır; bu nedenle, bir sunumcuyu bir görünüm için bağladığınızda, görünüm özellikleri arar ve verilerden nasıl çizim yapılacağını bilir. bunları ve kullanıcı tarafından kullanıcı arayüzünde bir değer değiştirildiğinde bunları nasıl ayarlayacağınızı.

Yani, örneğin, model bir araba ise, sunucu bir tür araba sunucusu ise, o zaman araba özelliklerini (yıl, yapımcı, koltuk vb.) görünüme açıklar. Görünüm, 'araba üreticisi' adlı metin alanının sunum yapan Maker özelliğini göstermesi gerektiğini biliyor.

Daha sonra birçok farklı sunum türünü görünüme bağlayabilirsiniz, hepsinin Maker özelliğine sahip olması gerekir - bir uçaktan, trenden veya ne olursa olsun, görünümün umrunda değil. Görünüm, sunucudan veri çeker - hangisi olursa olsun - kararlaştırılmış bir arayüz uyguladığı sürece.

Bu ciltleme çerçevesi, eğer sıyırırsanız, gerçekte denetleyici :-)

Ve böylece, MVP'ye, MVC'nin bir evrimi olarak bakabilirsiniz.

MVC harika, ancak sorun genellikle görüş başına denetleyicisi olması. A denetleyicisi, A görünümünün alanlarını nasıl ayarlayacağını bilir. Şimdi, A görünümünün B modelinin verilerini görüntülemesini istiyorsanız, B modelini tanımak için A denetleyicisine ihtiyacınız var ya da gibi bir arayüze sahip bir nesne almak için A denetleyicisine ihtiyacınız var. MVP yalnızca ciltlemeler olmadan veya UI ayar kodunu Denetleyici B'de yeniden yazmanız gerekir.

Sonuç - MVP ve MVC'nin her ikisi de UI modellerinin bir parçasıdır, ancak MVP genellikle altında MVC olan bir bağlama çerçevesi kullanır. THUS MVP, MVC'den daha yüksek bir mimari seviyede ve MVC'nin üstündeki bir sarma desenindedir.

    
8
2015-05-04 03: 17: 17Z

Mütevazi kısa görüşüm: MVP büyük ölçekler için ve MVC küçük ölçekler için. MVC'de bazen V ve C'nin doğrudan M'ye bağlı olan tek bir bölünmez bileşenin iki tarafı görülebildiğini hissediyorum ve UI kontrolleri ve temel widget'lar gibi daha kısa ölçeklere inerken kaçınılmaz olarak buna düşüyor. Bu ayrıntı düzeyinde MVP çok az anlam ifade eder. Aksine biri daha büyük ölçeklere gittiğinde, doğru bir arayüz daha önemli hale gelir, aynı şekilde sorumlulukların net bir şekilde verilmesiyle aynıdır ve işte MVP gelir.

Öte yandan, bu ölçekGenel kural, platform özellikleri, MVC'yi uygulamak için MVP'den daha kolay göründüğü web gibi, bileşenler arasındaki bir tür ilişkiyi desteklediğinde çok az kilo alabilir.

    
6
2013-02-20 16: 55: 37Z

Çok sayıda MVC sürümü var, bu cevap Smalltalk'taki orijinal MVC ile ilgili. Kısaca, öyle mvc vs mvp görüntüsü

Bu konuşma droidcon NYC 2017 - Mimari Bileşenlerle uygulama tasarımını temizleyin netleştirir

 Resim tanımını buraya girin buraya resim açıklamasını girin

    
3
2017-11-14 14: 06: 21Z
  1. MVP'yi her zaman kullanıyorum, sonra MVC olduğunu düşünüyorum
    2015-09-16 12: 15: 55Z
  2. MVC'de Model hiçbir zaman doğrudan görünümden çağrılmaz
    2015-10-29 07: 05: 36Z
  3. Bu yanlış bir cevaptır. Yanıltmayın. @ rodi'nin yazdığı gibi, Görünüm ve Model arasında etkileşim yoktur.
    2015-11-18 18: 35: 12Z
  4. MVC resmi yanlış veya en iyi yanıltıcı, lütfen bu cevaba hiç dikkat etmeyin.
    2015-12-07 15: 21: 46Z
  5. @ Jay1b Hangi MVC'nin "doğru" olduğunu düşünüyorsunuz? Bu cevap orijinal MVC ile ilgilidir. UIKit gibi diyelim ki, platforma adapte olacak başka MVC'ler de var (iOS'ta olduğu gibi).
    2017-11-14 14: 08: 17Z

    bu güzel video var Bob Amca’dan MVC’yi kısaca açıklar. Sonunda MVP.

    IMO, MVP, göstereceğiniz şeye (veri) gösterdiğinizden (görünüm) ilişkin kaygıyı temelden ayırdığınız MVC'nin geliştirilmiş bir sürümüdür. Sunucu, kullanıcı arabiriminizin iş mantığını içerir, hangi verilerin sunulması gerektiğini açık bir şekilde empoze eder ve size aptal görünüm modellerinin bir listesini verir. Ve verileri gösterme zamanı geldiğinde, görünümünüzü (muhtemelen aynı kimlikleri de içerir) bağdaştırıcınıza takmanız ve ilgili görünüm alanlarını, bu görünüm modellerini kullanarak minimum miktarda kod tanıtımıyla (yalnızca ayarlayıcıları kullanarak) ayarlayabilirsiniz. Bunun asıl yararı, kullanıcı arabirimi iş mantığınızı öğeleri yatay bir listede veya dikey listede göstermek gibi çeşitli /çeşitli görünümlere karşı test edebilmenizdir.

    MVC'de farklı katmanları yapıştırmak için arayüzler (sınırlar) üzerinden konuşuruz. Denetleyici mimarimize bir eklentidir, ancak ne göstereceğini dayatmak için böyle bir kısıtlama yoktur. Bu anlamda, MVP, denetleyiciye adaptörler üzerinden takılabilen görüş kavramına sahip bir MVC'dir.

    Bunun daha iyi olacağını umuyorum.

        
    3
    2018-07-02 22: 10: 29Z
    1. Bob Amca'dan gelen önemli nokta: Aslen Trygve Reenskaug tarafından icat edildiğinde, MVC tüm form için değil her widget için yapıldı.
      2019-01-12 00: 01: 12Z

    En basit cevap, görünümün modelle nasıl etkileşimde bulunduğudur. MVP'de görünüm, görünümle model arasında aracı görevi gören, görünümden girdi alan, modelden veri alan ve daha sonra bir iş mantığı gerçekleştiren ve sonunda görünümü güncelleyen sunucuya bağlanır. MVC'de model, denetleyiciden geri dönmek yerine, görünümü doğrudan günceller.

        
    2
    2018-06-12 10: 00: 42Z
    1. Reddedilmiştim, çünkü afaik modeli MVC'deki görünümle ilgili hiçbir şey bilmiyor ve yazdığınız gibi doğrudan güncelleme yapamıyor.
      2018-11-10 15: 58: 31Z
    2. Wikipedia'daki MVC'ye bakın, tam olarak böyle çalışıyor.
      2018-11-11 22: 43: 28Z
    3. Okuyucuların beğenip beğenmemesine bakılmaksızın, MVC'de görünümün modeldeki güncellemelere abone olduğunu googling ile bulunabilecek birçok kaynak var. ve bazı durumlarda denetleyici bile olabilir ve dolayısıyla bu tür güncellemeleri başlatır . Bundan hoşlanmıyorsanız, o makalelerden şikayet edin ya da oradaki mevcut bilgiyi ileten cevapları düşürmek yerine, tek meşru kaynak olduğunu düşündüğünüz 'incil'in hangisi olduğunu düşünüyorsunuz!
      2018-12-08 10: 21: 12Z
    4. İfadeler kesinlikle geliştirilebilir, ancak görünümün MVC'deki modeldeki değişikliklere abone olduğu doğrudur. Modelin MVC'deki Görünümü bilmesi gerekmez.
      2019-01-06 12: 50: 19Z

    Bence Erwin Vandervalk (ve beraberindeki makale ) MVC, MVP ve MVVM, benzerlikleri ve farklılıklarının en iyi açıklamasıdır. makale , "MVC, MVP ve MVVM" ile ilgili sorgular için arama motoru sonuçlarında görünmüyor, çünkü makalenin başlığı "MVC" ve "MVP" sözcüklerini içermiyor; ama bence en iyi açıklama bu.

    MVC, MVP ve MVVM'yi açıklayan resim - Erwin Vandervalk tarafından

    (The makale aynı zamanda Bob Martin Amca'nın görüşmelerinden birinde söyledikleriyle eşleşiyor: MVC'nin aslında sistemin mimarisi için değil, küçük UI bileşenleri için tasarlandığını gösteriyor)

        
    1
    2019-05-10 01: 43: 07Z

    MVP

    MVP, Model - Görünüm Sunucusu anlamına gelir. Bu, Microsoft'un Smart Client Windows uygulamalarını tanıttığı 2007'nin başlarında ortaya çıktı.

    Presenter, MVP'de olayları ve iş mantığını modellerden bağlayan bağlayıcı bir rol oynuyor.

    Görünüm etkinliği bağlama, Presenter'da bir görünüm arayüzünden uygulanacaktır.

    Görünüm, kullanıcı girişleri için başlatıcıdır ve ardından olayları Presenter'a devreder ve sunum yapan kişi, etkinlik bağlamalarını işler ve modellerden veri alır.

    Artıları:     Görünüm sadece kullanıcı arayüzüne sahip değil     Yüksek test edilebilirlik düzeyi

    Eksileri:     Etkinlik bağlayıcılarını uygularken biraz karmaşık ve daha fazla iş

    VC

    MVC, Model-View-Controller anlamına gelir. Kontrolör, model oluşturma ve ciltleme modelleriyle görünüm oluşturma işleminden sorumludur.

    Denetleyici, başlatıcıdır ve hangi görünümün oluşturulacağına karar verir.

    Artıları:   Tek Sorumluluk İlkesine Vurgule   Yüksek test edilebilirlik düzeyi

    Eksileri:   Bazen aynı denetleyicide birden çok görünüm oluşturmaya çalışırsanız Denetleyiciler için çok fazla iş yükü.

        
    - 1
    2016-01-12 04: 50: 54Z
kaynak yerleştirildi İşte