MVC kontrollü bir ortam ve MVVM reaktif bir ortamdır.
Kontrollü bir ortamda daha az koda ve ortak bir mantık kaynağına sahip olmalısınız; ki bunlar daima kontrolör içinde yaşamalıdır. Ancak; web dünyasında MVC kolayca görünüm oluşturma mantığı ve görünüm dinamik mantık ayrılır. Oluşturma sunucuda ve dinamik yaşam istemcide yaşar. AngularJS ile birleştirilmiş ASP.NET MVC ile bunu çok görüyorsunuz, oysa sunucu bir Görünüm oluşturacak ve bir Modelde geçecek ve istemciye gönderecektir. İstemci daha sonra Görünüm ile etkileşime girecektir; bu durumda AngularJS yerel bir denetleyici olarak devreye girer. Gönderildikten sonra Model veya yeni bir Model sunucu kontrolörüne aktarılır ve işlenir. (Bu nedenle döngü devam eder ve soketler veya AJAX vb.İle çalışırken bu işlemin birçok başka çevirisi vardır, ancak tüm mimari üzerinde aynıdır.)
MVVM reaktif bir ortamdır, yani bazı olaylara göre etkinleştirilecek kodu (tetikleyiciler gibi) yazarsınız. MVVM'nin geliştiği XAML'de, tüm bunlar dahili veri tabanı çerçevesi ile kolayca yapılabilir, ancak belirtildiği gibi, bu herhangi bir programlama diliyle herhangi bir Görünümdeki herhangi bir sistem üzerinde çalışacaktır. MS'e özgü değildir. ViewModel tetiklenir (genellikle özellik değiştirilmiş bir olaydır) ve Görünüm, oluşturduğunuz tetikleyicilere göre buna tepki verir. Bu teknik olabilir ama sonuçta Görünüm vatansız ve mantıksız. Sadece değerleri temel alarak durumu değiştirir. Ayrıca, ViewModels çok az mantıkla vatansızdır ve Modeller yalnızca durumu sürdürmeleri gerektiği için esasen Sıfır mantığı olan Devlettir. Bunu uygulama durumu (Model), durum tercümanı (ViewModel) ve sonra görsel durum / etkileşim (Görünüm) olarak tanımlıyorum.
Bir MVC masaüstü veya istemci tarafı uygulamasında bir Modeliniz olmalı ve Model Kontrolör tarafından kullanılmalıdır. Modele bağlı olarak, denetleyici Görünümü değiştirir. Görünümler genellikle Arayüzlü Denetleyicilere bağlanır, böylece Denetleyici çeşitli Görünümlerle çalışabilir. ASP.NET'te, Denetleyici Modelleri yönetirken ve Modelleri seçilen bir Görünüme geçirirken MVC mantığı sunucuda biraz geriye dönüktür. Görünüm daha sonra modele dayalı verilerle doldurulur ve kendi mantığı vardır (genellikle AngularJS ile yapılan gibi başka bir MVC seti). İnsanlar bunu MVC uygulamasıyla tartışacak ve karıştıracaklar ve her ikisini de yapmaya çalışacaklar. MVC kullanırken DAİMA mantığı ve kontrolü tek bir konuma koyun. Denetleyici veya Model verilerini barındırmak için Görünüm mantığını Görünüm'ün arkasındaki koda (veya Web için JS ile Görüntüle) yazmayın. Denetleyicinin Görünümü değiştirmesine izin verin. Bir Görünümde yaşaması gereken SADECE mantık, kullandığı Arayüz yoluyla oluşturmak ve çalıştırmak için gereken her şeydir. Bunun bir örneği bir kullanıcı adı ve şifre göndermektir. Masaüstü veya web sayfası (istemcide) olsun, Görünüm Gönder eylemini her tetiklediğinde Denetleyici gönderme işlemini gerçekleştirmelidir. Doğru bir şekilde yapılırsa, her zaman kolayca bir MVC web veya yerel uygulama etrafında yolunuzu bulabilirsiniz. Masaüstü veya web sayfası (istemcide) olsun, Görünüm Gönder eylemini her tetiklediğinde Denetleyici gönderme işlemini gerçekleştirmelidir. Doğru bir şekilde yapılırsa, her zaman kolayca bir MVC web veya yerel uygulama etrafında yolunuzu bulabilirsiniz. Masaüstü veya web sayfası (istemcide) olsun, Görünüm Gönder eylemini her tetiklediğinde Denetleyici gönderme işlemini gerçekleştirmelidir. Doğru bir şekilde yapılırsa, her zaman kolayca bir MVC web veya yerel uygulama etrafında yolunuzu bulabilirsiniz.
MVVM tamamen reaktif olduğu için şahsen benim favorim. Bir Model durumu değiştirirse, ViewModel bu durumu dinler ve çevirir ve hepsi bu !!! Görünüm daha sonra durum değişikliği için ViewModel'i dinler ve ayrıca ViewModel'den çeviriye göre güncellenir. Bazı insanlar buna saf MVVM diyorlar, ancak gerçekten sadece bir tane var ve nasıl tartıştığınız umurumda değil ve her zaman Görünümün kesinlikle mantık içermediği Saf MVVM.
İşte size küçük bir örnek: Diyelim ki bir tuşa basıldığında bir menü slaydı istiyorsunuz. MVC'de arayüzünüzde bir MenuPressed eylemi olacaktır. Denetleyici, Menü düğmesini tıklattığınızda ve ardından Görünüm'de Menü'de SlideMenuIn gibi başka bir Arayüz yöntemine göre kaymasını söylediğini bilecektir. Hangi nedenle gidiş-dönüş? Öyleyse Denetleyici başka bir şey yapamayacağınıza veya yapmak istemediğinize karar verir. Kontrol Ünitesi, Kontrol Ünitesi söylemedikçe, Görünüm hiçbir şey yapmadan Görünümden sorumlu olmalıdır. ANCAK; MVVM'de animasyondaki slayt menüsü yerleşik ve genel olmalıdır ve kaydırılması söylenmek yerine bazı değerlere dayanacaktır. Bu yüzden ViewModel'i dinler ve ViewModel derken IsMenuActive = true (veya bununla birlikte) bunun için animasyon gerçekleşir. Şimdi, Bununla birlikte başka bir noktaya değinmek istiyorum GERÇEKTEN TEMİZLE ve LÜTFEN dikkat edin. IsMenuActive muhtemelen BAD MVVM veya ViewModel tasarımıdır. Bir ViewModel tasarlarken hiçbir zaman bir Görünümün hiçbir özelliğe sahip olacağını varsaymamalısınız ve sadece çevrilmiş model durumunu geçmelisiniz. Bu şekilde, Menünüzü kaldırmak için Görünümünüzü değiştirmeye karar verirseniz ve verileri / seçenekleri başka bir yolla gösterirseniz, ViewModel umursamaz. Peki Menüyü nasıl yönetirsiniz? Veriler mantıklı olduğunda böyle. Bunu yapmanın bir yolu, Menüye bir seçenekler listesi (muhtemelen bir dizi iç ViewModel dizisi) vermektir. Bu listede veri varsa Menü tetikleyici aracılığıyla açmayı bilir, değilse tetikleyici aracılığıyla gizlenmeyi bilir. Sadece menü için verileriniz var veya ViewModel'de değil. Bu verileri ViewModel'de göstermeye / gizlemeye karar vermeyin. sadece Modelin durumunu çevirin. Bu şekilde Görünüm tamamen reaktif ve jeneriktir ve birçok farklı durumda kullanılabilir.
Her birinin mimarisine zaten en azından biraz aşina değilseniz ve net bir şekilde ALOT OF BAD bilgileri bulacağınızdan öğrenmek çok kafa karıştırıcı olabilirse, bunların hepsi kesinlikle mantıklı değildir.
Yani ... bunu doğru yapmak için akılda tutulması gereken şeyler. Uygulamanızı nasıl tasarlayacağınıza karar verin ve STICK TO IT.
Harika MVC yaparsanız, Kontrolörünüzün yönetilebilir olduğundan ve Görünümünüzün tam kontrolünde olduğundan emin olun. Büyük bir Görünüme sahipseniz, Görünüme farklı Denetleyicilere sahip denetimler eklemeyi düşünün. SADECE bu denetleyicileri farklı denetleyicilere kademelendirmeyin. Bakımı çok sinir bozucu. Bir dakikanızı ayırın ve işleri ayrı bileşenler olarak çalışacak şekilde ayrı ayrı tasarlayın ... Ve Denetleyicinin her zaman Model'e depolamayı taahhüt etmesini veya saklamasını söyleyin. MVC in için ideal bağımlılık ayarı Görünüm ← Denetleyici → Model veya ASP.NET ile (beni başlatma) Model ← Görünüm ↔ Denetleyici → Model (Model, Denetleyiciden Görünüm'e tamamen aynı veya tamamen farklı bir Model olabilir)... elbette bu noktada Görünümde Kontrolör'ü bilmenin tek ihtiyacı, çoğunlukla bir Modelin nereye geçeceğini bilmek için uç nokta referansıdır.
Eğer MVVM yaparsan, senin tür ruhunu kutsuyorum, ama SAĞ yapmak için zaman ayırın! Biri için arabirimler kullanmayın. Görünümünüzün değerlere dayalı olarak nasıl görüneceğine karar vermesine izin verin. View with Mock verileriyle oynayın. Eğer o zaman istemiyor olsanız bile (örnek olarak) size bir menü gösteren bir görünüm sahip olursanız o zaman İYİ. Görüşünüz olması gerektiği gibi çalışıyor ve değerlere olması gerektiği gibi tepki veriyor. ViewModel belirli bir çevrilmiş durumda olduğunda bunun gerçekleşmediğinden emin olmak için tetikleyicinize birkaç gereksinim daha ekleyin veya ViewModel'e bu durumu boşaltması için komut verin. ViewModel'inizde, sanki oradan Görünüm'ün görüp görmeyeceğine karar veriyorsanız, bunu dahili mantıkla SİLMEYİN. ViewModel'de bir menü olduğunu varsayamayacağınızı unutmayın. Ve sonunda, Model sadece durumu değiştirmenize ve büyük olasılıkla mağaza durumunu değiştirmenize izin vermelidir. Doğrulama ve her şey burada gerçekleşecek; örneğin, Model durumu değiştiremezse, kendisini kirli veya başka bir şey olarak işaretler. ViewModel bunu fark ettiğinde, kirli olanı çevirir ve ardından View bunu fark eder ve başka bir tetikleyici aracılığıyla bazı bilgileri gösterir. Görünümdeki tüm veriler ViewModel'e bağlanabilir, böylece her şey yalnızca dinamik olabilir ve ViewModel, View'un bağlayıcıya nasıl tepki vereceği konusunda hiçbir fikre sahip değildir. Aslında Modelin bir ViewModel fikri de yok. Bağımlılıklar kurarken, bu şekilde ve sadece böyle işaret etmelidirler. t durumu değiştirmek o zaman sadece kirli veya başka bir şey olarak işaretler. ViewModel bunu fark ettiğinde kirli olanı çevirir ve Görünüm bunu fark eder ve başka bir tetikleyici aracılığıyla bazı bilgileri gösterir. Görünümdeki tüm veriler ViewModel'e bağlanabilir, böylece her şey yalnızca dinamik olabilir ve ViewModel, View'un bağlayıcıya nasıl tepki vereceği konusunda hiçbir fikre sahip değildir. Aslında Modelin bir ViewModel fikri de yok. Bağımlılıklar kurarken, bu şekilde ve sadece böyle işaret etmelidirler. t durumu değiştirmek o zaman sadece kirli veya başka bir şey olarak işaretler. ViewModel bunu fark ettiğinde, kirli olanı çevirir ve ardından View bunu fark eder ve başka bir tetikleyici aracılığıyla bazı bilgileri gösterir. Görünümdeki tüm veriler ViewModel'e bağlanabilir, böylece her şey yalnızca dinamik olabilir ve ViewModel, View'un bağlayıcıya nasıl tepki vereceği konusunda hiçbir fikre sahip değildir. Aslında Modelin bir ViewModel fikri de yok. Bağımlılıklar kurarken, bu şekilde ve sadece böyle işaret etmelidirler. Görünümdeki tüm veriler ViewModel'e bağlanabilir, böylece her şey yalnızca dinamik olabilir ve ViewModel, View'un bağlayıcıya nasıl tepki vereceği konusunda hiçbir fikre sahip değildir. Aslında Modelin bir ViewModel fikri de yok. Bağımlılıklar kurarken, bu şekilde ve sadece böyle işaret etmelidirler. Görünümdeki tüm veriler ViewModel'e bağlanabilir, böylece her şey yalnızca dinamik olabilir ve ViewModel, View'un bağlayıcıya nasıl tepki vereceği konusunda hiçbir fikre sahip değildir. Aslında Modelin bir ViewModel fikri de yok. Bağımlılıklar kurarken, bu şekilde ve sadece böyle işaret etmelidirler.Görünüm → ViewModel → Modeli (ve bir yan burada not ... ve bu muhtemelen sıra savundu alacak ama umurumda değil ... DO NOT PASS MODEL GÖRÜNÜM o MODEL değişmez sürece, aksi takdirde a ile sarın Görünüm model bir dönem görmemelidir. Bir sıçanlara gördüğünüz demoyu ya da nasıl yaptığınızı araştırıyorum, bu yanlış.)
İşte son ipucum ... İyi tasarlanmış, ancak çok basit bir MVC uygulamasına bakın ve bir MVVM uygulaması için de aynısını yapın. Biri sınırlı esneklikle daha fazla kontrole sahipken, diğeri hiçbir kontrole ve sınırsız esnekliğe sahip olmayacak.
Kontrollü bir ortam, tüm uygulamayı bir dizi denetleyiciden veya (tek bir kaynaktan) yönetmek için iyidir; reaktif bir ortam, uygulamanın geri kalanının ne yaptığına dair hiçbir fikre sahip olmadan ayrı depolara ayrılabilir. Mikro yönetim ve serbest yönetime karşı.
Sizi yeterince karıştırmadıysam, benimle iletişime geçmeyi deneyin ... Bunu örnek ve örneklerle ayrıntılı olarak ele almayı umursamıyorum.
Günün sonunda hepimiz programcıyız ve kodlama sırasında içimizde anarşi yaşıyor ... Kurallar çiğnenecek, teoriler değişecek ve tüm bunlar domuz yıkamasıyla sonuçlanacak ... Ama büyük üzerinde çalışırken projelerde ve büyük ekiplerde, bir tasarım deseni üzerinde anlaşmaya ve onu uygulamaya yardımcı olur. Bir gün, başlangıçta atılan küçük ekstra adımların daha sonra tasarrufların sıçraması ve sınırları haline gelmesini sağlayacaktır.
