Soru MVP ve MVC nedir ve fark nedir?


Ötesine bakarken RAD (sürükle-bırak ve konfigüre et) kullanıcı arayüzleri oluşturmanın yolu, birçok aracın üç tasarım modeline rastlamanızı teşvik ettiğini Model-View-Controller, Model-View-Presenter ve Model-View-ViewModel. Soruma göre üç bölüm var:

  1. Bu modeller hangi konuları ele alıyor?
  2. Nasıl benzerler?
  3. Nasıl farklılar?

1839
2017-08-05 10:06


Menşei


mvc.givan.se/#mvp - givanse
IDK, ama orijinal MVC için sözde, küçük kullanılacaktı. Her düğme, etiket, vb. Kendi görüş ve denetleyici nesnesine sahipti ya da en azından Bob Amca'nın iddia ettiği şey buydu. Bence Smalltalk hakkında konuşuyordu. YouTube'daki görüşmelere bakın, onlar büyüleyici. - still_dreaming_1
MVP, View-Controller'ı bir View ve Presenter'a bölerek ekstra bir dolaylı katman katıyor ... - the_prole
Ana fark, MVC'de Kontrolörün Model'den View'a herhangi bir veri iletmemesidir. Sadece verileri Model'den almak için View'a bildirir. Ancak, MVP'de, Görünüm ve Model arasında bir bağlantı yoktur. Sunum Yapan kişi, Model'den gereken verileri alır ve göstermesi için View'a aktarır. Tüm mimari desenlerde bir android örneğiyle birlikte daha fazlası burada: digigene.com/category/android/android-architecture - Ali Nem


Cevaplar:


Model-View-Presenter

İçinde MVP, Presenter View için UI iş mantığını içerir. Gösterge temsilcisinden gelen tüm çağrılar doğrudan Sunum Yapan. Presenter ayrıca doğrudan View'den ayrılır ve bir arayüz üzerinden konuşur. Bu, bir birim testinde Görünümün alay edilmesine izin vermektir. MVP'nin ortak bir özelliği, iki yönlü bir gönderimin olması gerektiğidir. Örneğin, birisi "Kaydet" düğmesini tıkladığında, olay işleyicisi Presenter'ın "OnSave" yöntemine delege eder. Kaydetme tamamlandıktan sonra, Presenter, View (Arac) 'ı View (Arayüzü) üzerinden geri çağırır, böylece View (Kaydet), kaydının tamamlandığını görüntüleyebilir.

MVP, Web Formlarında ayrı bir sunum yapmak için çok doğal bir model olma eğilimindedir. Nedeni, Görünüm her zaman ilk ASP.NET çalışma zamanı tarafından oluşturulur. Yapabilirsin her iki varyant hakkında daha fazla bilgi edinin.

İki temel varyasyon

Pasif Görünüm: Görünüm mümkün olduğu kadar aptal ve neredeyse sıfır mantığı içerir. Presenter, Görünüm ve Model ile konuşan orta bir adamdır. Görünüm ve Model birbirinden tamamen korumalıdır. Model olayları artırabilir, ancak Sunum Yapan kişi, Görünümü güncellemek için onlara abone olur. Pasif Görünümde, doğrudan veri bağlama yoktur, bunun yerine Görünüm, Sunucunun verileri ayarlamak için kullandığı ayarlayıcı özelliklerini sergiler. Tüm durum Sunumda değil, Görüntülemede yönetilir.

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

Denetleyici Denetçisi: Presenter, kullanıcı hareketlerini yönetir. Görünüm, veri bağlama yoluyla doğrudan Model'e bağlanır. Bu durumda, Sunucunun Model'i Görünüm'e iletmesi, böylece ona bağlanabilmesidir. Presenter ayrıca bir düğmeye basma, gezinme vb. Gibi hareketler için mantık da içerecektir.

  • Pro: veri tabanından yararlanarak kod miktarı azalır.
  • Con: daha az test edilebilir yüzey (veri bağlama nedeniyle) vardır ve Model'de doğrudan konuştuğu için Görünüm'de daha az kapsülleme vardır.

Model-View-Controller

İçinde MVCDenetleyici, uygulamanın yüklendiğinde 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österge Sunucusuna yönlendirildiği MVP'den farklıdır. MVC'de, Görünüm'deki her eylem, bir eylemle birlikte bir Denetleyiciye yapılan bir çağrıyla ilişkilidir. Web'de her eylem, diğer taraftaki bir Denetleyicinin yanıt verdiği bir URL'ye yapılan bir çağrıyı içerir. Denetleyici işlemeyi tamamladıktan sonra doğru Görünümü döndürür. Sıra, uygulamanın ömrü boyunca bu şekilde devam eder:

Görünümde Eylem
        -> Kontrolöre Çağrı
        -> Denetleyici Mantığı
        -> Denetleyici, Görünümü döndürür.

MVC ile ilgili bir diğer büyük fark, Görünüm'ün doğrudan Model'e bağlanmasıdır. Görüş, sadece vatansız ve tamamen vatansız. MVC uygulamalarında, Görünüm genellikle arka planda kodda herhangi bir mantık olmayacaktır. Bu, kesinlikle gerekli olduğu MVP'ye aykırıdır, çünkü eğer Görüntü Sunum Yapıcısına delege etmezse, asla çağrılmaz.

Sunum Modeli

Bakmak için bir başka desen Sunum Modeli Desen. Bu modelde Presenter yok. Bunun yerine Görünüm doğrudan bir Sunum Modeline bağlanır. Sunum Modeli, özellikle Görünüm için hazırlanmış bir Modeldir. Bu, bu Modelin, bir alan adı modeline asla konmayacak özellikleri açığa çıkararak, ayrılma kaygılarının ihlali anlamına gelebileceği anlamına gelir. Bu durumda, Sunum Modeli, etki alanı modeline bağlanır ve bu Modelden gelen olaylara abone olabilir. Görünüm, Sunum Modelinden gelen olaylara abone olur ve buna göre kendini günceller. Sunum Modeli, görünümün eylemleri çağırmak için kullandığı komutları gösterebilir. Bu yaklaşımın avantajı, kodun tamamen arkaplanını tamamen ortadan kaldırabilmenizdir, çünkü PM, görünümün tüm davranışlarını tamamen kapsülleyecektir. Bu model, WPF uygulamalarında kullanılmak için çok güçlü bir adaydır ve ayrıca denir Model-View-ViewModel.

Var Sunu Modeli ile ilgili MSDN makalesi ve içinde bir bölüm WPF için Kompozit Uygulama Kılavuzu hakkında (eski Prism) Ayrılmış Sunum Kalıpları


1803
2017-08-05 10:21



Bu cümleyi açıklayabilir misiniz? Bu, eylemlerin Gösterge Sunucusuna yönlendirildiği MVP'den farklıdır. MVC'de, Görünüm'deki her eylem, bir eylemle birlikte bir Denetleyiciye yapılan bir çağrıyla ilişkilidir. Bana göre, aynı şey gibi geliyor, ama eminim farklı bir şey açıklıyorsunuz. - Panzercrisis
@Panzercrisis Bu, yazarın ne anlama geldiğinden emin değilim, ama söylediklerini düşünüyorum. Bu cevap gibi - stackoverflow.com/a/2068/74556 MVC'de, denetleyici yöntemleri davranışlara dayanır - başka bir deyişle, birden çok görüntüyü (aynı davranışı) tek bir denetleyiciyle eşleştirebilirsiniz. MVP'de, sunucu görüşe daha yakın bağlanır ve genellikle bire-bire yakın olan bir eşleme ile sonuçlanır, yani bir görüntüleme eylemi, karşılık gelen sunucunun yöntemine eşleşir. Normalde başka bir görüntünün eylemlerini başka bir sunum yapan kişinin (başka bir görünümden) yöntemiyle eşleştiremezsiniz. - Dustin Kendall


Bunun hakkında bir süre önce blog yazdım, alıntı yapıyorum Todd Snyder'ın ikisi arasındaki farkın mükemmel mesajı:

İşte arasındaki önemli farklar   desenler:

MVP Modeli

  • Görünüm modele daha gevşek bir şekilde bağlıdır. Sunucu   modeli bağlamadan sorumlu   görünüm.
  • Birim sınaması daha kolaydır, çünkü görünüm ile etkileşim   bir arayüz
  • Genellikle haritayı bire bir sunumu görüntüleyin. Karmaşık manzaralar olabilir   çoklu sunumcular.

MVC Modeli

  • Denetleyici davranışları temel alır ve   görünümler
  • Hangi görünümün görüntüleneceğinin belirlenmesinden sorumlu olabilir

Bu, bulabildiğim web'deki en iyi açıklamadır.


385
2017-07-06 22:18



Her iki durumda da bütün noktanın onları tamamen ayrıştırması gerektiğinde, bakış açısının modele ne kadar yakın bir şekilde bağlanabileceğini anlamıyorum. Yanlış bir şey söylediğini ima etmiyorum - ne demek istediğinle ilgili. - Bill K
@pst: MVP ile gerçekten 1 Görünüm = 1 Presenter. MVC ile, Denetleyici çoklu görünümleri yönetebilir. Bu gerçekten. "Sekmeler" modeli ile her sekmenin, tüm sekmeler için bir Denetleyiciye sahip olmanın tersine kendi Sunucusuna sahip olduğunu hayal edin. - Jon Limjap
Başlangıçta iki tür denetleyici vardır: birden çok görünümde paylaşılacağı söylenen ve özellikle paylaşılan denetleyicinin arabirimini uyarlamak için özel olarak görüntülenen kişiler. - Acsor
@JonLimjap Yine de bir görünümle ne anlama geliyor? İOS programlama bağlamında, tek ekranlı mı? Bu iOS'un kontrolörünü MVC'den çok MVP'ye benzetiyor mu? (Öte yandan, ekran başına birden çok iOS kontrol cihazına da sahip olabilirsiniz) - huggie
Peki Todd'un MVC'nin diyagramatik çizimi tamamen Görünüm ve Modelin ayrıştırma fikriyle çelişir. Şemaya bakarsanız, Model güncellemeleri Görüntüle (Modelden Görünüm'e ok). Hangi evrende, modelin doğrudan View ile etkileştiği bir sistem, bir deşifre edilmiş bir ??? - Ash


Bu, bu tasarım modellerinin birçok varyantının aşırı basitleştirilmesidir, ancak bu ikisi arasındaki farklılıkları düşünmeyi seviyorum.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Bu, şematik bir betimlemedir ve bu, herhangi bir GUI'nin (görüntüleme nesnesi) ilgili tümünün, görüntüleyicinin API'sinden soyutlanmasını ve tam olarak izole edilmesini gösterir. Bir minör nokta: Her bir görüş için değil, yalnızca bir sunum yapan yerde bir ana sunucu kullanılabilir, ancak diyagramınız en temiz olanıdır. IMO, MVC / MVP arasındaki en büyük fark, MVP'nin mevcut “görüş durumu” nı görüntülemekten başka bir şeyden tamamen uzak tutmaya çalıştığı (verileri görüntülemeyi) ve aynı zamanda Model nesneleri hakkındaki bilgileri görmezden gelmeye çalıştığıdır. Böylece, orada olması gereken arayüzler, bu durumu enjekte etmek için.
İyi resim. MVP'yi çok kullanıyorum, bu yüzden bir puan yapmak isterim. Benim tecrübelerime göre, Sunum yapanların sık sık birbirleriyle konuşması gerekiyor. Aynı Modeller (veya Ticari nesneler) için de geçerlidir. MVP resminizde yer alan bu ek "mavi çizgiler" sayesinde Presenter-Model ilişkileri oldukça dolaşmış olabilir. Bu nedenle, bire-bire karşı bire-bir Presenter-Model ilişkisini sürdürme eğilimindeyim. Evet, Model üzerinde bazı ek delege yöntemleri gerektirir, ancak Modelin API'sinin değişmesi veya yeniden yapılandırmaya ihtiyacı olması durumunda birçok baş ağrısını azaltır. - splungebob
MVC örneği yanlıştır; Görünümler ve denetleyiciler arasında sıkı bir 1: 1 ilişki var. Tanım gereği, bir denetleyici, modele yönelik olaylar üretmek ve tek bir denetim için benzer görünüm sağlamak için insan hareketi girdisini yorumlar. Daha basit olarak, MVC sadece bireysel widget'larla kullanılmak üzere tasarlanmıştır. Bir widget, bir görünüm, bir kontrol. - Samuel A. Falvo II
@ SamuelA.FalvoII her zaman değil, bir 1 var: ASP.NET MVC'de denetleyiciler ve görünümler arasında birçok: stackoverflow.com/questions/1673301/... - StuperUser
@StuperUser - Bunu yazarken ne düşündüğümden emin değilim. Elbette haklısın, ve yazdıklarımı tekrar gözden geçirdim, aklımda bulunamadığım başka bir bağlamım olup olmadığını merak etmeliyim. Düzeltme için teşekkürler. - Samuel A. Falvo II


İşte iletişim akışını gösteren resimler

enter image description here 

enter image description here


210
2017-08-25 21:22



MVC diyagramıyla ilgili bir sorum var. Veriyi almak için görünümün nereye gittiğini anlamadım. Kontrolörün gerekli verilerle görüntüyü ileteceğini düşünürdüm. - Brian Rizo
Bir kullanıcı bir düğmeyi tıklarsa, bu görünümle nasıl etkileşime girmez? MVC'de gibi hissediyorum, kullanıcı kontrolörden daha fazla görüntü ile etkileşime giriyor - Jonathan
Bunun eski bir cevap olduğunu biliyorum - ama JonathanLeaders'ın üzerine kimse cevap verebilir mi? Bazı benzersiz kodlamalar yapmadığınız sürece winforms arkaplanından geliyorum, UI / View tıklattığınızda bu tıklama hakkında herhangi bir şeyden önce bilgi alırsınız. En azından bildiğim kadarıyla? - Rob P.
@RobP. Bu tür grafiklerin her zaman çok karmaşık ya da çok basit olduğunu düşünüyorum. MVP grafiğinin akışı, MVC uygulaması için de geçerlidir. Dil özelliklerine (veri bağlama / gözlemci) bağlı olarak varyasyonlar olabilir, fakat sonuçta, uygulamanın görünümü / mantığından görünümü ayrıştırmaktır. - Luca Fülbier
@JonathanLeaders İnsanlar var Gerçekten mi "MVC" dedikleri zaman akılda kalan farklı şeyler. Bu grafiği yaratan kişi, "kullanıcı girişi" nin HTTP istekleri olduğu ve "kullanıcıya döndürülen görünüm" öğesinin işlenen bir HTML sayfası olduğu düşünüldüğünde, muhtemelen klasik Web MVC'si göz önünde bulunduruldu. Dolayısıyla, bir kullanıcı ve bir görüş arasındaki herhangi bir etkileşim, klasik Web MVC uygulamasının bir yazarı açısından "varolmayan" dır. - cubuspl42


MVP değil mutlaka Görünümün sorumlu olduğu bir senaryo (örneğin Taligent'in MVP'sine bakınız).
İnsanların bunun bir anti-örüntüden ziyade “sadece bir görüş” (Pragmatik Programcı) ile çeliştiği için bir desen (Şarjdan sorumlu) olarak vaaz etmelerini talihsiz buluyorum. "Sadece bir görüş", kullanıcıya gösterilen son görünümün uygulamanın ikincil bir endişesi olduğunu belirtir. Microsoft'un MVP modeli, Görüntülemelerin yeniden kullanımını çok daha zorlaştırıyor ve elverişli Microsoft'un tasarımcısı kötü uygulamaları cesaretlendiriyor.

Tam olarak açık olmak gerekirse, MVC'nin temel kaygılarının 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, o zaman MVC'nin faydalarını göreceksiniz demektir. . Faydaları sağladıysanız, o zaman sizin modelinizin MVC, MVP veya Supervising Controller olup olmadığına kim gerçekten önem veriyor? Tek gerçek desen MVC olarak kalır, geri kalanı sadece farklı lezzetleri vardır.

Düşünmek bu Bu farklı uygulamaların bir çoğunu kapsamlı olarak listeleyen son derece heyecan verici bir makale. Bunların hepsinin temelde aynı şeyi yaptıklarını ama biraz farklı olduğunu unutmayın.

Ben şahsen, MVP'nin, bir şeylerin gerçekten MVC olup olmadığını veya Microsoft'un Hızlı Uygulama Geliştirme araçlarını haklı çıkardığını iddia eden semantik büyükler arasındaki argümanları azaltmak için yakın zamanda akılda kalıcı bir terim olarak yeniden kullanıldığını düşünüyorum. Kitaplarımdaki bu nedenlerden hiçbiri, varlığını ayrı bir tasarım deseni olarak doğrulamaktadır.


149
2017-08-06 22:51



MVC / MVP / MVVM / etc 'arasındaki farklar hakkında birçok cevap ve blog okudum. Aslında, işin başına geldiğinde, hepsi aynı. Arabiriminizin olup olmadigi ve ayarlayici (veya herhangi bir dil özelligi) kullanip kullanmayacaginiz farketmez. Bu kalıplar arasındaki farkın, bir kavram meselesinden ziyade çeşitli çerçevelerin uygulamalarındaki farktan doğduğu görülmektedir. - Michael
MVP'yi arayamazdım. Anti-desenDaha sonra postda "MVP de dahil olmak üzere" [MVC] 'nin sadece farklı lezzetleridir. ", eğer MVP bir anti-pattern ise, MVC ise ... sadece bir lezzet farklı bir çerçevenin yaklaşımı. (Şimdi, biraz özel MVP uygulamaları, bazılarından daha fazla veya daha az arzu edilebilir özel Farklı görevler için MVC uygulamaları ...)
@Quibblsome: “Ben şahsen MVP'nin, bir şeyin gerçekten MVC olup olmadığını tartışan semantik büyükler 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 iki nedenden ötürü hiçbiri varlığını haklı çıkarmaz. Ayrı tasarım deseni. ” Bunu belirgin hale getirmek için yeterince farklıdır. MVP'de, görünüm önceden tanımlanmış bir arabirimi 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 yapılır (ilişkilerin bir başkası başka bir terime değeceğini hissettirirse). - Hibou57
@ Hibou57, MVC'nin görünümü bir arabirim olarak referans göstermekten veya birkaç farklı görünüm için genel bir kontrol birimi oluşturmasından hiçbir şey yoktur. - Quibblesome
@quibblesome aslında var. Kontrolörler, tanım olarak, ilgili görüşlere sıkı sıkıya bağlıdır, çünkü yaptıkları iş, insan hareketlerini (tuşa basma, fare güncellemeleri vb.) bireysel kontroller bir pencerede. Bu yüzden sıkı bir denetleyiciniz var, bir görüş ilişkisi var. Kontrolörler vardı asla Form çapında kullanım için tasarlanmıştır. Form çapında kullanım için, bu amaca daha uygun olan Uygulama Modeli (Sunum Modeli) ortaya çıktı. Smalltalk GUI'leri kontrolleri uygulamak için MVC'ye güvenmediğinden, MVC uygulamada nispeten az anlam ifade eder. - Samuel A. Falvo II


MVP: görünüm sorumludur.

Çoğu durumda görünüm, sunucusunu oluşturur. Sunucu modelle etkileşime girecek ve görünümü bir arayüz üzerinden yönlendirecektir. Görünüm bazen sunucuyla, genellikle bazı arayüzlerle etkileşime girer. Bu, uygulamaya indiriliyor; Görüntüleyicinin sunum yapan kişiyi arama yöntemlerini çağırmasını mı istiyorsunuz yoksa görüntünün sunum yapan kişinin dinlediği olayların olmasını mı istiyorsunuz? Bu aşağı kaynar: Görüş, sunucu hakkında bilir. Görünüm sunucuya delege eder.

MVC: denetleyici sorumludur.

Denetleyici, bazı olaylara / isteklere bağlı olarak 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ğıya doğru kaymaktadır: denetleyici görünümü oluşturur ve yönetir; Görünüm denetleyiciye bağımlıdır. Görünüm denetleyici hakkında bilmiyor.


90
2017-12-20 02:10



"Görünüm Denetleyici hakkında bilmiyor." Bence bu görüşün modelle doğrudan bir ilişkisi olmadığı anlamına mı geliyor? - Lotus Notes
Görünüm, eiether modeldeki modeli asla bilmemelidir. - Brian Leahy
@Brian: “Görünüm çoğu durumda Presenter'ı yaratıyor.”. Presenter'ın hem Modeli hem de Görünümü başlatmasıyla çoğunlukla tersini gördüm. Peki, Görünüm Sunucuyu da başlatabilir, ancak bu nokta aslında en belirgin değil. En önemli olan şey, daha sonra ömür boyu en çok gerçekleşir. - Hibou57
Daha fazla açıklamak için cevabınızı düzenlemek isteyebilirsiniz: Görünüm Denetçi hakkında bilgi sahibi olmadığı için, kullanıcının ekran üzerinde gördüğü 'görsel' elemanlar üzerinde gerçekleştirilen (örneğin Görünüm) Denetleyici'ye iletilen kullanıcı eylemleri nasıldır? ... - Ash


enter image description here

MVC (Model Görüntüleme Denetleyicisi)

Giriş, önce değil, kontrolöre yönlendirilir. Bu giriş, bir sayfa ile etkileşimde bulunan bir kullanıcıdan geliyor olabilir, ancak belirli bir URL’yi bir tarayıcıya girmekten de olabilir. Her iki durumda da, bazı işlevselliği başlatmak için arabirimine sahip bir Denetleyici. Denetleyici ve Görünüm arasında bire bir ilişki var. Bunun nedeni, tek bir denetleyicinin, yürütülmekte olan işleme bağlı olarak işlenecek farklı görünümleri seçebilmesidir. Denetleyiciden Görünüm'e giden tek yönlü oku unutmayın. Bunun nedeni, Görünümün denetleyici hakkında herhangi bir bilgisi veya referansı olmamasıdır. Denetleyici Modeli geri gönderir, bu nedenle Görünüm ile beklenen Modelin kendisine geçirilmesi arasında bilgi vardır, ancak bunu sağlayan Denetçi'yi değil.

MVP (Model Görüntü Sunucusu)

Giriş, Presenter ile değil, Görünüm ile başlar. Görünüm ve ilgili Presenter arasında bire bir eşleme var. Görünüm, Presenter'a bir referans tutar. Sunum yapan kişi ayrıca, Görünüm'den tetiklenen olaylara da tepki gösterir, dolayısıyla View ile ilişkili olduğunu fark eder. Presenter, Modeli, Model üzerinde gerçekleştirdiği istenen eylemleri temel alarak güncelleştirir; ancak Görünüm, Modelin farkında değildir.

Daha fazlası için Referans


62
2017-08-05 10:22



Ama içinde MVP Uygulama, uygulama ilk kez yüklendiğinde, ilk görüntüyü yüklemek sunucudan sorumlu değildir. Örneğin facebook uygulamasını yüklediğimizde, giriş sayfasını yüklemek sorumlu olan kişi değil midir? - viper
MVC'de Model'den View'a bir bağlantı mı? Cevabınızı, bunun bu bağlantıyı kullanarak 'ayrıştırılmış' bir sistem haline getirdiğini açıklamak için düzenlemek isteyebilirsiniz. İpucu: Bunu zor bulabilirsin. Ayrıca, okuyucunun mutluluğu kabul etmediğini düşünmedikçe, tüm yaşamı boyunca yanlış hesaplıyorlarsa, kullanıcının ekrandaki 'görsel' öğelerle etkileşime girmesine rağmen, MVC'de ilk önce Denetleyiciden nasıl geçtiğini ayrıntılandırmak isteyebilirsiniz. Görüntüle), işlemenin ardında oturan soyut bir katman değil. - Ash
Bu kabul edilen cevap olmalı. açık ve özlü - Nelson Ramirez


  • MVP = Model-View-Presenter
  • MVC = Model-Görünüm-Denetleyici

    1. Her iki sunum modeli. Bir Model (Düşünen Alan nesneleri), ekranınız / web sayfanız (Görünüm) ile kullanıcı arayüzünüzün nasıl davranması gerektiği arasındaki bağımlılıkları ayırır (Sunum Yapan / Denetleyen)
    2. Konsepte oldukça benzerler, insanlar Sunum / Denetleyiciyi tat almaya bağlı olarak farklı şekilde başlatırlar.
    3. Farklılıklar hakkında harika bir makale İşte. En önemlisi, MVC modelinin Görünüm'ü güncelleyen Modele sahip olmasıdır.

31
2017-08-08 05:55



VIew'i güncelleyen model. Ve bu hala ayrıştırılmış bir sistem mi? - Ash


Ayrıca hatırlamaya değer, farklı türde MVP'ler de vardır. Fowler, deseni ikiye ayırdı - Pasif Görünüm ve Denetleme Denetleyicisi.

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 doğrudan eşleme özelliklerine sahip ince taneli bir arayüz uygular. Örneğin, Ad ve Adres gibi özelliklere sahip bir ICustomerView'iniz olabilir.

Uygulamanız şunun gibi görünebilir:

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üntüye "eşleyecektir". Bu yaklaşım "Pasif Görünüm" olarak adlandırılır. Yarar, testin kolay bir şekilde test edilmesi ve UI platformları (Web, Windows / XAML, vb.) Arasında geçiş yapmak daha kolaydır. Dezavantajı databinding gibi şeyleri kaldıramayacağınızdır. Gerçekten mi gibi çerçevelerde güçlü WPF ve Silverlight).

MVP'nin ikinci lezzeti Denetleyici Kontrolördür. Bu durumda, Görünümünüzün Müşteri olarak adlandırılan bir özelliği olabilir. Bu, daha sonra UI widget'larına veri olarak gönderilir. Görünümü senkronize etmeyi ve mikro-yönetmeyi düşünmek zorunda değilsiniz ve Denetleyici Kontrolör, ihtiyaç duyulduğunda örneğin etkileşimli etkileşim mantığıyla işe yarayabilir ve yardımcı olabilir.

MVP'nin üçüncü "lezzeti" (veya belki de ona ayrı bir desen diyebiliriz) Sunum Modelidir (veya bazen Model-View-ViewModel'e atıfta bulunur). MVP'ye kıyasla M ve P'yi bir sınıfa "birleştirirsiniz". UI widget'larınızın veriye bağlı olduğu müşteri nesnesine sahipsiniz, ancak "IsButtonEnabled" veya "IsReadOnly" gibi ek UI özelliklerine de sahipsiniz.

UI mimarisine ulaştığım en iyi kaynağın Jeremy Miller tarafından yapılan blog yayınları dizisi olduğunu düşünüyorum. Kendi CAB Serisi İçindekiler. MVP'nin tüm lezzetlerini kapladı ve bunları uygulamak için C # kodu gösterdi.

Ayrıca, Silverlight bağlamında Model-View-ViewModel modeli hakkında blog yazdım. YouCard Yeniden ziyaret edildi: ViewModel modelinin uygulanması.


31
2018-04-06 13:51





Sorunun pek çok cevabı var, ama ikisini açıkça kıyaslayan gerçekten basit bir cevaba ihtiyaç olduğunu hissettim. Bir kullanıcı MVP ve MVC uygulamasında bir film adı aradığında yaptığım tartışma:

Kullanıcı: Tıklayın…

Görünüm: Kim o? [MVP|MVC]

Kullanıcı: Arama düğmesine tıkladım…

Görünüm: Tamam, bir saniye bekle…. [MVP|MVC]

( Görünüm çağırıyor sunucu|kontrolör …) [MVP|MVC]

Görünüm: Hey sunucu|kontrolörBir Kullanıcı sadece arama düğmesine bastı, ne yapmalıyım? [MVP|MVC]

sunucu|kontrolör: Hey Görünüm, bu sayfada herhangi bir arama terimi var mı? [MVP|MVC]

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

sunucu: Teşekkürler Görünüm... arada sırada arama terimini arıyorum model, lütfen ona bir ilerleme çubuğu göster [MVP|MVC]

( sunucu|kontrolör çağırıyor model …) [MVP|MVC]

sunucu|kontrolör: Hey model, Bu arama terimi için herhangi bir eşleşme var mı ?: “piyano” [MVP|MVC]

model: Hey sunucu|kontrolör, kontrol edeyim … [MVP|MVC]

( model film veritabanına bir sorgu yapıyor…) [MVP|MVC]

( Bir süre sonra ... )

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

model: Senin için bir liste buldum sunucuBurada JSON “[{" isim ":" Piyano Öğretmeni "," yıl ": 2001}, {" isim ":" Piyano "," yıl ": 1993}]” [MVP]

model: Bazı sonuç mevcut, kontrolör. Örneğimde bir alan değişkeni oluşturdum ve sonuçla doldurdum. Adı "searchResultsList" [MVC]

(sunucu|kontrolör Teşekkürler model ve geri alır Görünüm) [MVP|MVC]

sunucu: Beklediğiniz için teşekkürler Görünüm, Sizin için eşleşen sonuçların bir listesini buldum ve bunları önceden belirlenmiş bir biçimde düzenledim: ["Piyano Öğretmeni 2001", "Piyano 1993"]. Lütfen kullanıcıya dikey listede göster. Ayrıca lütfen şimdi ilerleme çubuğunu gizleyin [MVP]

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

Görünüm: Çok teşekkür ederim sunucu [MVP]

Görünüm: Teşekkür ederim "Controller" [MVC] (Şimdi Görünüm Kendini sorguluyor: Ben elde ettiğim sonuçları nasıl sunmalıyım model kullanıcıya Filmin yapım yılı birinci mi yoksa sonuncu mu? Dikey veya yatay bir listede mi olmalı? ...)

İlgilenirseniz, bir Github repo eşliğinde uygulama mimari kalıpları (MVC, MVP, MVVP, temiz mimarlık, ...) ile ilgili bir dizi makale yazdım. İşte. Örnek android için yazılmış olsa da, temel prensipler herhangi bir ortama uygulanabilir.


18
2017-08-05 10:20





Bu çerçevelerin her ikisi de endişeleri ayırmayı amaçlamaktadır - örneğin, bir veri kaynağı (model) ile etkileşim, uygulama mantığı (veya bu verileri yararlı bilgilere dönüştürmek) (Denetleyici / Sunum) ve ekran kodu (Görünüm). Bazı durumlarda model ayrıca bir veri kaynağını daha yüksek seviyeli bir soyutlamaya çevirmek için de kullanılabilir. Bunun iyi bir örneği MVC Storefront projesi.

Bir tartışma var İşte MVC vs MVP arasındaki farklar.

Yapılan bir ayrım, bir MVC uygulamasında geleneksel olarak görüşe sahip ve kontrolörün modelle etkileşime girdiği, fakat birbiriyle değil.

MVP tasarımları Presenter'a modele erişir ve görünümle etkileşime girer.

Bunu söyledikten sonra, ASP.NET MVC, bu tanımlarla bir MVP çerçevesidir, çünkü Kontrolör, Mantığa sahip olmadığı anlamına gelen Görünümü doldurmak için Modele erişir (sadece Kontrolör tarafından sağlanan değişkenleri gösterir).

MVP'den ASP.NET MVC ayrımına dair bir fikir edinmek için bu MIX sunusu Scott Hanselman tarafından.


16
2018-03-13 05:54



MVC ve MVP kalıp değil, kalıplardır. Eğer dürüstçe düşünürseniz, bu konu .NET framework'le ilgiliydi, o zaman “internet” i duymak ve IE ile ilgili olduğunu düşünmek gibi bir şey. - tereško
Oldukça emin soru ilk kez 2008 yılında geri sorulduğunda ortaya çıkmıştır. Ayrıca, cevabıma baktığımda (ve bu 4 yıl önceydi bu yüzden senden çok daha fazla içerik yok) genel olarak başladığımı söyleyebilirim ve Daha sonra .NET MVC'yi somut bir örnek olarak kullanın. - Matt Mitchell