MVC'deki 'C' gerçekten gerekli mi?

Modelin ve Model-Denetleyici modelindeki görüntünün rolünü anlıyorum, ancak bir denetleyicinin neden gerekli olduğunu anlamakta zorlanıyorum.

Bir MVC yaklaşımı kullanarak bir satranç programı yarattığımızı varsayalım; oyun durumu model olmalı ve GUI de görünüm olmalıdır. Bu durumda kontrolör tam olarak nedir?

Bir döşemeye tıkladığınızda çağrılacak tüm fonksiyonlara sahip olan ayrı bir sınıf mı? Neden manzaranın tüm mantığını görünümün kendisinde göstermiyoruz?

Örneğinizi kullanarak, Denetleyici, yasal bir hamle olup olmadığına karar veren şey olurdu. Kontrolör, Modelden aldığı bilgileri kullanarak başlangıçta tahtadaki parçaları nasıl düzenleyeceğini bilecektir. Denetleyici tarafından idare edilebilecek daha çok şey var, ancak anahtar, bu katmandaki İş Mantığı hakkında düşünmektir.

Tüm Denetleyicinin yaptığı bilgilerin, bir kayıt sayfası gibi ileri geri bilgi ilettiği zamanlar vardır. Diğer zamanlarda, Denetleyici, geliştirmenin zor kısmıdır, çünkü kuralları uygulamak veya karmaşık bir matematik yapmak gibi o katmanda yapılması gereken birçok şey vardır. Kontrol Ünitesini unutma!

Neden manzaranın tüm mantığını görünümün kendisinde göstermiyoruz?

Kontrolör, modeli birbirine bağlayan ve görüntüleyen yapıştırıcıdır ve aynı zamanda onları ayrı tutan yalıtımdır. Model görünüm hakkında hiçbir şey bilmemeli ve tersi (en azından Apple'ın MVC versiyonunda). Kontrolör, iki yönlü bir adaptör gibi çalışır, kullanıcı eylemlerini görünümden modele mesajlara dönüştürür ve görünümü modelden verilerle yapılandırır.

Model ve görünümü ayırmak için denetleyiciyi kullanmak, kodunuzu daha tekrar kullanılabilir, daha test edilebilir ve daha esnek hale getirir. Satranç örneğini düşün. Model elbette oyun durumunu da içerecektir, ancak aynı zamanda bir hareketin yasal olup olmadığını belirlemek ve oyunun ne zaman biteceğine karar vermek gibi oyun durumundaki değişiklikleri etkileyen mantığı da içerebilir. Görünüm bir satranç tahtasını görüntüler ve bir parça hareket ettiğinde parçaları gönderir ve gönderir, ancak parçaların arkasındaki anlam, her parçanın nasıl hareket ettiği vb. Hakkında hiçbir şey bilmez. Denetleyici hem model hem de görünüm hakkında hem de bilir programın genel akışı. Kullanıcı 'yeni oyun' düğmesine bastığında, modele bir oyun oluşturmasını söyleyen ve yeni oyunun durumunu tahta kurmak için kullanan bir denetleyicidir. Kullanıcı bir hamle yaparsa,

Modelinizi koruyarak elde ettiğinize bakın ve ayrı görüntüleyin:

• Diğerini değiştirmeden modeli veya görünümü değiştirebilirsiniz. Her ikisini de değiştirdiğinizde denetleyiciyi güncellemeniz gerekebilir, ancak bu bir açıdan avantajın bir parçası: Programın değişmesi en muhtemel kısımları denetleyicide yoğunlaşmış durumda.

• Model ve görünüm yeniden kullanılabilir. Örneğin, ünlü satranç oyunları için bir model olarak bir RSS beslemesiyle aynı satranç tahtası görünümünü kullanabilirsiniz. Veya aynı modeli kullanabilir ve görünümü web tabanlı bir arayüzle değiştirebilirsiniz.

• Gerektiği gibi çalıştıklarından emin olmak için hem model hem de görünüm için testler yazmak kolaydır.

• Hem model hem de görünüm genellikle standart parçalardan yararlanabilir: diziler, haritalar, kümeler, dizeler ve model için diğer veri kapları; düğmelere, kontrollere, metin alanlarına, görüntü görünümlerine, tablolara ve görünüm için diğerlerine.

Bu genel tasarım modelini uygulamanın birçok farklı yolu vardır, ancak temel fikir çeşitli endişeleri gereken şekilde ayırmaktır. MVC şu anlamda güzel bir soyutlamadır:

Model : Bu veriyi, ne anlama geldiğini ifade eder
Görünüm : Kullanıcı arayüzünü, bu ne anlama geldiğini ifade eder
Denetleyici : Bu model ve görüntünün etkileşimde bulunmasına neden olan yapıştırıcıyı, bu ne anlama gelebilirse onu temsil eder.

Son derece esnektir, çünkü çok fazla bir şey belirtmez. Birçok insan her bir öğenin ne anlama gelebileceğinin ayrıntılarını, bunun yerine hangi adların kullanılması gerektiğini ve gerçekten 3 veya 2 veya 4 veya 5 bileşeninin olup olmadığını tartışarak çok fazla bant genişliği boşa harcar. belirli bir derece.

Fikir, mantığın farklı "parçalarını" birbirleriyle örtüşmemek için ayırmak. Sunum öğelerinizi bir arada tutun, verilerinizi bir arada tutun, mantıklarınızı bir arada tutun, iletişiminizi bir arada tutun. Ve bunun gibi. Bir dereceye kadar, bu endişe alanları ne kadar az örtüşüyorsa, onlarla ilginç şeyler yapmak o kadar kolay olur.

Gerçekten endişelenmen gereken tek şey bu.

Şimdiye kadar tüm iyi cevaplar. Benim iki kuruş, kontrolörün öncelikle Ne ve nerede olduğu gibi sorularla oluşturulduğunu düşünmekten hoşlanıyorum.

• Bir satranç taşının (manzara) x'e taşınabileceği sorulmuştu. O mi
  izin? Emin değilim ama nereye ve kime soracağımı biliyorum (model).
• Bir şey benden verilerimi korumamı istedi. Bunu nasıl yaparım? Nerede soracağımı biliyorum! Verileri nasıl kaydettiğimizi veya nereye kaydedildiğini, hiçbir fikrim yok, ancak bu Repository sınıfı bilmeli. İleriye götüreceğim ve onunla ilgilenmesine izin vereceğim.
• Şu anki satranç taşının konumunu, kullanıcıya modelin taşıdığı kullanıcıya göstermeliyim. parçayı yeşil mi yoksa sarı mı göstermek istediğimden emin değil miyim? Bah, kimin umrunda, bununla başa çıkacak bir görüş olduğunu biliyorum, bu yüzden verileri ileteceğim ve nasıl gösterileceğine karar verebilirler.

Bu küçük parçacıklar, soyutlamayı hatırlamaya çalıştığım örneklere ve MVC'nin aktarmaya çalıştığı kavramlara örnek olarak veriliyor. Ne, Nerede ve Nasıl Üç Ana Düşünce Süremim?

Ne ve nerede => Kontrolör Nasıl ve ne zaman => Modeller ve görüşler

Temelde, denetleyici eylemlerim küçük ve kompakt olma eğilimindedir ve bunları okurken bazen zaman kaybı gibi görünme eğilimindedir. Yakından yapılan denetlemede, trafik görevlileri olarak hareket ediyorlar, çeşitli talepleri çalışan işçilere yönlendiriyorlar, ancak asıl işin hiçbirini yapmıyorlar.

Bir Kontrolör, hem Görünümün hem de Modelin arayüzlerinin soyutlanmasına yardımcı olabilir, böylece birbirlerini doğrudan tanımaları gerekmez. Bir nesne ne kadar az bilmek zorunda olursa, o kadar taşınabilir ve birim test edilebilir hale gelir.

Örneğin, Model bir Kontrolörden kendisinin başka bir örneğini oynuyor olabilir. Veya ağa bağlı bir Denetleyici iki oyuncunun Görünüm nesnelerini birbirine bağlayabilir. Ya da kimsenin hangisini bilmediği bir Turing sınavı olabilir.

Olay işleyicileriyle uğraşırken gerçekten devreye giriyor, ancak görünüm ile model arasındaki etkileşimleri idare edebilmek için hala denetleyiciye ihtiyacınız var. İdeal olarak, görünümün modelle ilgili hiçbir şey bilmesini istemezsiniz. Bir düşün, tüm jsp aramalarını doğrudan yapmak için bir jsp ister misiniz? (Bir giriş araması gibi bir şey olmadıkça.) Görünüm oluşturma mantığı değil, görünüm oluşturma mantığı değil, iş mantığına sahip olmadıkça görünümün veri oluşturmasını ve herhangi bir iş mantığına sahip olmamasını istiyorsunuz.

GWT'de MVP ile daha temiz bir ayrılık elde edersiniz. Görünümde herhangi bir iş mantığı yoktur (doğru yapılırsa). Sunucu denetleyici olarak davranır ve görünümün modeli hakkında bilgisi yoktur. Model verileri görünüme basitçe aktarılır.

Belge Görünümü (yani model görünümü), MFC'de yazılmış Windows uygulamalarının çoğu için standart bir modeldir, bu nedenle birçok durumda çalışması gerekir.

Modelin ve Model-Denetleyici modelindeki görüntünün rolünü anlıyorum, ancak bir denetleyicinin neden gerekli olduğunu anlamakta zorlanıyorum.

Bundan emin misiniz? (En azından başlangıçta tanımlandığı gibi) Modelin amacı, etki alanı modeli olmaktır. Görünümün etki alanı modelini kullanıcıya göstermesi beklenir. Kontrolörün düşük seviye girişini yüksek seviye model konuşması ile eşlemesi gerekir. Akıl yürütmenin söyleyebileceğim kadarıyla, şu satırlar boyunca bir şey olduğunu: A) SRP'nin yüksek düzeyde kullanımı. B) Model, uygulamanın önemli bir parçası olarak kabul edildi, bu yüzden önemsiz ve daha hızlı değişen şeyleri bunun dışında tutun. C) kolayca test edilebilir (ve senaryoya uyumlu) iş mantığı.

Sadece satranç programınızı kör tarafından kullanılabilir hale getirmek istiyorsanız, sesli bir versiyonun görüntüsünü ve klavyeyle çalışan bir kontrol cihazını değiştirin. Posta ile oyun eklemek istediğinizi varsayalım, metni kabul eden bir denetleyici ekleyin. Oyunun net versiyonu? Bir soketten komutları kabul eden bir denetleyici işi yapar. Güzel bir 3d görünüm, yeni bir görünüm ekleyin. Sıfır model gerekli değişiklikleri satranç hala satranç.

Girdiyi model gösterimi ile karıştırırsanız, bu yeteneği kaybedersiniz. Birden Satranç Satranç değil, bir klavye veya ağ bağlantısı olan Satranç'tan farklı bir fareyle satranç.

MVC'nin aptalca olduğunu düşünüyorum, belki belirli alanlarda iyi çalışıyor ama şahsen yazdığım web siteleri bile mvc için uygun değil. Ön uç, arka uç ve asla veritabanı sonu ya da başka bir sonu olmayan şeyler duymanızın bir nedeni var

IMO bir API (arka uç) ve API (ön uç) kullanan uygulama olmalıdır. Sanırım GET talebini denetleyiciyi (basitçe apend'i çağıran) ve görünümü html olarak çağırabilirsin fakat genelde insanların saf html veya modelinin arka uç API olduğu şeklinde konuştuğunu duymuyorum.

IMO her şey sağlam bir API olmalıdır. Aslında sağlam olmaları gerekmez (temiz ve iyi yapılmışlarsa da), ancak iç kısımları özel kalmalı ve api'nin uygulaması / ön uç / dışında hiçbir zaman veritabanı bağlantısı söylenmemeli veya ham sorgular yapamamalıdır.

Şimdi eğer kodunuz / tasarımınız tutkal içeriyorsa, para cezası. Eğer satranç oyununda GUI'yi düzenlemek için düzenleyebileceğiniz bazı işaretler varsa, GUI kodları / girişi toplar ve geçerli bir hamle olup olmadığını söylemek için bir bool veya enum döndüren MovePiece'yi (srcPosition, dstPostion) çağırır. ) ve tüm mantık modelinde olmanın tamam olduğunu kesin olarak söyleyiniz. Ancak yine de şeyleri sınıflara ve API'lere göre düzenler ve her şeye (veya her şey hakkında bilmek zorunda olan herhangi bir API'ye) dokunan hiçbir mutfak lavabosu sınıfı olmadığından emin olurdum.

Statik bir web sayfası görüntüleyen bir tarayıcı düşünün. Model HTML'dir. Görünüm, ekrandaki gerçek sonuçtur.

Şimdi biraz JavaScript ekleyin. Bu Denetleyici. Kullanıcı bir düğmeyi tıklattığında veya Etkinlik'in JavaScript'e gönderdiği bir şeyi sürüklediğinde, ne yapılması gerektiğine karar verir ve temel HTML'yi (Model) değiştirir ve tarayıcı / oluşturucu bu değişiklikleri ekranda görüntüler (Görünüm).

Belki başka bir düğme tıklatılırsa, etkinlik bazı işleyicilere (Denetleyici) gönderilir ve bir web servisine daha fazla veri gönderilmesi için bir talebe yol açabilir. Sonuç daha sonra HTML’ye (Model) eklenir.

Kontrolör olaylara cevap verir ve Modelde ne olduğunu ve dolayısıyla ekranda ne olduğunu kontrol eder.

Biraz geri adım attığınızda, tüm tarayıcıyı Görünüm ve sunucu olarak Denetleyici ve verileri Model olarak düşünebilirsiniz. Kullanıcı, sunucuya gönderdiği olay tarayıcıda bir düğmeyi tıklattığında (Denetleyici), kaynakları bir HTML sayfası (Model) olarak toplar ve görüntülenecek tarayıcıya geri gönderir (Görüntüle)

Sunucuda, asp, php veya java olup olmadığını 'code' (Controller) click olayını alır ve bir veritabanı veya belge deposunu sorgular (Model) ve HTML oluşturur. Sunucu bakış açısından, tüm eylemlerinin sonucu, temel veri deposunun (Modeli) bir Görünümüdür (HTML). Ancak müşteri bakış açısına göre, sunucuya isteğinin sonucu Modelidir (HTML).

JavaScript'inizi HTML'nizde karıştırsanız veya HTML'nizde PHP'nizi karıştırsanız bile Model, Görünüm, Denetleyici hala var. Bir sunucuya olan isteğinizi ve sunucudan gelen yanıtları iki yönlü basit bir cadde olarak düşünseniz bile, bir Model, Görünüm ve Denetleyici var.

Deneyimlerime göre, geleneksel bir masaüstü mvc gui programında, denetleyici görünüme göre spagetti ile sonuçlanıyor. Çoğu kişi denetleyici sınıfını etkisiz hale getirmek için zaman ayırmaz.

dörtlü çete kitabında şöyle yazıyor:

Smalltalk MVC'de Tasarım Desenleri

Sınıfların Model / View / Controller (MVC) üçlüsü [KP88], Smalltalk-80'de kullanıcı arayüzleri oluşturmak için kullanılır. MVC içindeki tasarım modellerine bakmak, "kalıp" terimiyle ne demek istediğimizi görmenize yardımcı olmalıdır.

MVC üç çeşit nesneden oluşur. Model uygulama nesnesi, Görünüm ekran sunumu ve Denetleyici, kullanıcı arabiriminin kullanıcı girdisine verdiği tepkiyi tanımlar. MVC'den önce, kullanıcı arayüzü tasarımları bu nesneleri bir araya getirme eğilimindeydi. MVC esnekliği artırmak ve tekrar kullanmak için onları ayırır.

MVC, aralarında bir abone olma / bildirme protokolü kurarak görünümleri ve modelleri ayırır. Bir görünüm, görünümünün modelin durumunu yansıtmasını sağlamalıdır. Modelin verileri değiştiğinde, model ona bağlı görünümleri bildirir. Yanıt olarak, her görünüm kendini güncelleme fırsatı buluyor. Bu yaklaşım, farklı sunumlar sağlamak için bir modele birden çok görünüm eklemenizi sağlar. Ayrıca, bir model için yeniden yazmadan yeni görünümler oluşturabilirsiniz.

Aşağıdaki şemada bir model ve üç görünüm gösterilmektedir. (Basitlik için denetleyicileri dışarıda bıraktık.) Model bazı veri değerleri içeriyor ve bir elektronik tablo, histogram ve pasta grafiğini tanımlayan görünümler bu verileri çeşitli şekillerde gösteriyor. Model, değerleri değiştiğinde görüşleri ile iletişim kurar ve bu değerlere erişmek için görünümler modelle iletişim kurar.

Gerçek değeri üzerinden alındığında, bu örnek modellerden görünümleri ayıran bir tasarımı yansıtır. Ancak tasarım daha genel bir soruna uygulanabilir: nesnelerin ayrıştırılması, böylece değişiklik yapılması, değiştirilen nesnenin diğerlerinin ayrıntılarını bilmesini gerektirmeden herhangi bir diğerini etkileyebilir. Bu daha genel tasarım, Gözlemci (sayfa 293) tasarım deseni ile tanımlanmıştır.

MVC'nin bir başka özelliği de görünümlerin iç içe geçebilmesidir. Örneğin, düğmelerin kontrol paneli iç içe düğme görünümleri içeren karmaşık bir görünüm olarak uygulanabilir. Bir nesne denetçisinin kullanıcı arayüzü, bir hata ayıklayıcıda yeniden kullanılabilecek iç içe görünümlerden oluşabilir. MVC, bir Görünümün alt sınıfı olan CompositeView sınıfıyla iç içe görünümleri destekler. CompositeView nesneleri, yalnızca View nesneleri gibi davranır; bir görüntünün kullanılabileceği her yerde bileşik görünüm kullanılabilir, ancak iç içe görünümleri de içerir ve yönetir.

Yine, bunu, bileşenlerinden birine yaptığımız gibi, bileşik bir görüntüye bakmamızı sağlayan bir tasarım olarak düşünebiliriz. Ancak tasarım, nesneleri gruplamak ve gruba bireysel bir nesne gibi davranmak istediğimizde ortaya çıkan daha genel bir soruna uygulanabilir. Bu daha genel tasarım, Kompozit (163) tasarım deseni ile tanımlanmaktadır. Bazı alt sınıfların ilkel nesneleri (örneğin, Düğme) tanımladığı bir sınıf hiyerarşisi oluşturmanıza izin verir ve diğer sınıflar, ilkelleri daha karmaşık nesnelere birleştiren bileşik nesneleri (CompositeView) tanımlar.

MVC ayrıca, görsel sunumunu değiştirmeden bir görüntünün kullanıcı girdisine yanıt verme şeklini değiştirmenizi sağlar. Örneğin, klavyeye tepki verme şeklini değiştirmek veya komut tuşları yerine bir açılır menü kullanmasını isteyebilirsiniz. MVC, cevap mekanizmasını bir Controller nesnesine yerleştirir. Sınıf kontrolörleri hiyerarşisi var ve mevcut kontrol cihazında bir varyasyon olarak yeni bir kontrol cihazı oluşturmayı kolaylaştırıyor.

Görünüm, belirli bir yanıt stratejisini uygulamak için Denetleyici alt sınıfının bir örneğini kullanır; farklı bir strateji uygulamak için örneği sadece farklı bir denetleyici ile değiştirin. Görünümün kullanıcı girişine yanıt verme biçimini değiştirmesine izin vermek için görünümün denetleyicisini çalışma zamanında değiştirmek bile mümkündür. Örneğin, bir görünüm, giriş olaylarını görmezden gelen bir denetleyici vererek girişi kabul etmemesi için devre dışı bırakılabilir.

View-Controller ilişkisi, Strateji (315) tasarım modelinin bir örneğidir. Strateji, bir algoritmayı temsil eden bir nesnedir. Algoritmayı statik veya dinamik olarak değiştirmek istediğinizde, algoritmanın çok fazla değişkenine sahip olduğunuzda veya algoritmanın kapsüllemek istediğiniz karmaşık veri yapılarına sahip olması yararlıdır.

MVC, bir görünüm için varsayılan denetleyici sınıfını belirtmek için Fabrika Yöntemi (107) ve bir görünüme kaydırma eklemek için Dekoratör (175) gibi diğer tasarım desenlerini kullanır. Ancak MVC'deki ana ilişkiler Gözlemci, Kompozit ve Strateji tasarım kalıpları tarafından verilmektedir.