MVC mimarisine giriş
Her programcının bildiği en popüler uygulama mimarisi MVC'dir . MVC, Model-View-Controller'ın kısaltmasıdır .
Bu, uygulama bileşenlerinin mimarisi kadar uygulamaların mimarisi değildir, ancak bu nüansa daha sonra geri döneceğiz. MVC nedir?
MVC, uygulama verilerini ve kontrol mantığını model, görünüm ve denetleyici olmak üzere üç ayrı bileşene ayırmaya yönelik bir şemadır , böylece her bileşen bağımsız olarak değiştirilebilir.
- Model (Model), veri sağlar ve durumunu değiştirerek denetleyici komutlarına yanıt verir.
- Görünüm, model değişikliklerine yanıt olarak model verilerini kullanıcıya göstermekten sorumludur.
- Denetleyici (Denetleyici), kullanıcının eylemlerini yorumlar ve modele değişiklik ihtiyacını bildirir.
Bu model 1978 (!) Yılında icat edildi. Evet, uygun yazılım mimarisiyle ilgili sorunlar 50 yıl önce geçerliydi. Bu modelin orijinaldeki diyagramla nasıl açıklandığı aşağıda açıklanmıştır:
Model, bunlarla çalışmak için veriler ve yöntemler sağlar: veritabanına yapılan sorgular, doğruluğun kontrolü. Model, görünümden (verilerin nasıl işleneceğini bilmez) ve denetleyiciden (kullanıcı etkileşim noktalarına sahip değildir) bağımsızdır ve verilere erişim ve veri yönetimi sağlar.
Model, isteklere durumunu değiştirerek cevap verecek şekilde inşa edilmiş ve "gözlemcilerin" bildirimi yerleşik hale getirilebilir. Model, görsel temsilden bağımsız olması nedeniyle, bir "model" için birkaç farklı temsile sahip olabilir .
Görünüm, modelden gerekli verileri almak ve kullanıcıya göndermekten sorumludur. Görünüm, kullanıcı girişini işlemez.
Kontrolör, kullanıcı ve sistem arasındaki "iletişimi" sağlar. Verileri kontrol eder ve kullanıcıdan sisteme yönlendirir ve tersi de geçerlidir. İstenen eylemi uygulamak için bir model ve bir görünüm kullanır.
Bu modelin on yıllar içinde biraz evrimleşmiş olması gerçeğiyle ilgili belirli bir zorluk var. Yani isim aynı kaldı ama bölümlerin amacı değişmeye başladı.
Web üzerinde MVC mimarisi
MVC tasarım modelinin arkasındaki fikir çok basit: uygulamalarımızdaki farklı davranışların sorumluluğunu açıkça ayırmamız gerekiyor:
modeli— veri işleme ve uygulama mantığı.
görüş— kullanıcıya desteklenen herhangi bir biçimde veri sağlama.
Denetleyici- kullanıcı isteklerinin işlenmesi ve uygun kaynakların çağrılması.
Uygulama, her biri farklı görevlerden sorumlu olan üç ana bileşene ayrılmıştır. Bir örnek kullanarak bir istemci-sunucu uygulamasının bileşenlerine daha yakından bakalım.
Denetleyici
Kullanıcı, tarayıcıdaki sayfadaki çeşitli öğelere tıklar ve bunun sonucunda tarayıcı çeşitli HTTP istekleri gönderir: GET, POST veya diğerleri. Denetleyici, sayfa içinde çalışan tarayıcıyı ve JS kodunu içerebilir.
Bu durumda denetleyicinin ana işlevi, gerekli nesneler üzerinde yöntemleri çağırmak, kullanıcı tarafından belirtilen görevleri gerçekleştirmek için kaynaklara erişimi yönetmektir. Tipik olarak, denetleyici görev için uygun modeli çağırır ve uygun görünümü seçer.
modeli
Geniş anlamda model, verilerle çalışmak için kullanılan veriler ve kurallardır - birlikte uygulamanın iş mantığını oluştururlar. Bir uygulama tasarlamak her zaman üzerinde çalıştığı nesnelerin modellerini oluşturmakla başlar.
Diyelim ki kitap satan bir çevrimiçi mağazamız var, o zaman kişi sadece bir uygulama kullanıcısı mı yoksa aynı zamanda bir kitabın yazarı mı? Bu önemli sorular model tasarımı sırasında ele alınmalıdır.
Ayrıca bir dizi kural vardır: ne yapılabilir, ne yapılamaz, hangi veri kümeleri kabul edilebilir ve hangileri kabul edilemez. Yazarsız kitap olur mu? Ve kitapsız yazar? Kullanıcının doğum tarihi 300 yılında olabilir mi vb.
Model, denetleyiciye kullanıcının talep ettiği verilerin (mesaj, kitap sayfası, resimler vb.) bir görünümünü verir. Veri modeli, kullanıcıya nasıl sunmak istersek isteyelim aynı olacaktır. Bu nedenle, verileri görüntülemek için mevcut herhangi bir görünümü seçiyoruz.
Model, uygulama mantığımızın en önemli bölümünü , uğraştığımız sorunu (forum, mağaza, banka vb.) çözen mantığı içerir. Denetleyici, çoğunlukla uygulamanın kendisi için organizasyon mantığı içerir (tıpkı Proje Yöneticiniz gibi).
Görüş
Görünüm, modelden alınan verileri temsil etmek için çeşitli yollar sağlar. Verilerle dolu bir şablon olabilir. Birkaç farklı görünüm olabilir ve denetleyici mevcut durum için hangisinin en iyi olduğunu seçer.
Bir web uygulaması genellikle bir dizi denetleyici, model ve görünümden oluşur. Denetleyici yalnızca arka uçta olabilir, ancak mantığı ön uca da yayıldığında birkaç denetleyicinin bir çeşidi de olabilir. Bu yaklaşımın iyi bir örneği, herhangi bir mobil uygulamadır.
Web'de MVC örneği
Diyelim ki kitap satacak bir çevrimiçi mağaza geliştirmeniz gerekiyor. Kullanıcı aşağıdaki eylemleri gerçekleştirebilir: kitapları görüntüleyin, kaydedin, satın alın, mevcut siparişe ürün ekleyin, beğendiği kitapları işaretleyin ve satın alın.
Uygulamanızın tüm iş mantığından sorumlu bir modeli olmalıdır. Ayrıca , tüm kullanıcı eylemlerini işleyecek ve bunları iş mantığından yöntem çağrılarına dönüştürecek bir denetleyiciye ihtiyacınız var . Ancak, bir denetleyici yöntemi birçok farklı model yöntemini çağırabilir.
Ayrıca görünüm kümelerine de ihtiyacınız vardır: kitap listesi, kitap hakkında bilgi, alışveriş sepeti, sipariş listesi. Bir web uygulamasının her sayfası, aslında modelin belirli bir yönünü kullanıcıya gösteren ayrı bir görünümdür.
Bakalım bir kullanıcı, kitapçıların tavsiye ettiği kitapların listesini açarak kitaplarını incelerse ne olacak. Tüm eylem dizisi 6 adım şeklinde açıklanabilir:
Adımlar:
- Kullanıcı "önerilen" bağlantısını tıklar ve tarayıcı /books/recommendations gibi bir istek gönderir.
- Denetleyici isteği kontrol eder : kullanıcı oturum açmış olmalıdır. Veya oturum açmamış kullanıcılar için kitap koleksiyonlarımız olmalıdır. Denetleyici daha sonra modeli çağırır ve ondan N kullanıcısına önerilen kitapların listesini döndürmesini ister.
- Model veri tabanına erişir, oradan kitaplarla ilgili bilgileri alır: şu anda popüler olan kitaplar, kullanıcı tarafından satın alınan kitaplar, arkadaşları tarafından satın alınan kitaplar, istek listesindeki kitaplar. Model, bu verilere dayanarak önerilen 10 kitaplık bir liste oluşturur ve bunları denetleyiciye geri gönderir.
- Denetleyici önerilen kitapların bir listesini alır ve ona bakar. Bu aşamada, denetleyici kararları verir! Birkaç kitap varsa veya liste tamamen boşsa, oturum açmamış bir kullanıcı için bir kitap listesi ister. Şu anda devam eden bir promosyon varsa, denetleyici promosyon kitaplarını listeye ekleyebilir.
- Kontrolör, kullanıcıya hangi sayfanın gösterileceğini belirler. Bir hata sayfası, kitap listesinin olduğu bir sayfa, kullanıcının bir milyonuncu ziyaretçi olmasını kutlayan bir sayfa olabilir.
- Sunucu, istemciye denetleyici tarafından seçilen sayfayı ( görünüm ) verir. Gerekli verilerle (kullanıcı adı, kitap listesi) doldurulur ve müşteriye gider.
- İstemci sayfayı alır ve kullanıcıya gösterir.
Bu yaklaşımın faydaları nelerdir?
MVC konseptini kullanmaktan elde ettiğimiz en belirgin avantaj, sunum mantığı (kullanıcı arayüzü) ile uygulama mantığının (arka uç) açık bir şekilde ayrılmasıdır.
İkinci avantaj, sunucu bölümünün ikiye bölünmesidir: akıllı model ( yürütücü ) ve denetleyici ( karar merkezi ).
Önceki örnekte, denetleyicinin modelden boş bir önerilen kitap listesi alabileceği ve onunla ne yapacağına karar verebileceği bir an vardı. Teorik olarak, bu mantık doğrudan modele konulabilir.
İlk olarak, model önerilen kitapları isterken, liste boşsa ne yapılacağına karar verirdi. O zaman kodu aynı yere eklemek zorunda kalırdım, şimdi bir promosyon varsa ne yapmalıyım, sonra daha farklı seçenekler.
Ardından, mağaza yöneticisinin kullanıcının sayfasının promosyon olmadan nasıl görüneceğini görmek istediği veya tam tersi, şu anda promosyon olmadığı, ancak gelecekteki promosyonun nasıl gösterileceğini görmek istediği ortaya çıktı. Ve bunun için herhangi bir yöntem yok. Bu nedenle karar merkezinin (denetleyici) iş mantığından (model) ayrılmasına karar verildi.
Görünümleri uygulama mantığından izole etmenin yanı sıra MVC konsepti, büyük uygulamaların karmaşıklığını büyük ölçüde azaltır. Kod, çözümlerin bakımını, test edilmesini ve yeniden kullanılmasını kolaylaştıracak şekilde çok daha yapılandırılmıştır.
MVC kavramını anlayarak, bir geliştirici olarak, kitap listesini sıralamayı nereye eklemeniz gerektiğini anlarsınız:
- Veritabanı sorgu düzeyinde.
- İş mantığı (model) düzeyinde.
- İş mantığı düzeyinde (denetleyici).
- Görünümde - istemci tarafında.
Ve bu retorik bir soru değil. Şimdi, kitap listesini sıralamak için kodu nereye ve neden eklemeniz gerektiğini düşünün.
Klasik MVC Modeli
MVC bileşenleri arasındaki etkileşim, web uygulamalarında ve mobil uygulamalarda farklı şekilde gerçekleştirilir. Bunun nedeni, web uygulamasının kısa ömürlü olması, bir kullanıcı isteğini işleyip çıkması, mobil uygulamanın ise birçok isteği yeniden başlatmadan işleme koymasıdır.
Web uygulamaları tipik olarak "pasif" modeli kullanırken, mobil uygulamalar "aktif" modeli kullanır. Aktif model, pasif olanın aksine, abone olmanıza ve içindeki değişikliklerle ilgili bildirimler almanıza olanak tanır. Web uygulamaları için bu gerekli değildir.
Çeşitli modellerdeki bileşenlerin etkileşimi şöyle görünür:
Mobil uygulamalar (aktif model), olayları ve olay abonelik mekanizmasını aktif olarak kullanır. Bu yaklaşımla, view ( view ) model değişikliklerine abone olur. Ardından, bir olay meydana geldiğinde (örneğin, kullanıcı bir düğmeyi tıklattığında), denetleyici çağrılır . Ayrıca modele verileri değiştirmek için bir komut verir .
Bazı veriler değiştiyse, model bu verileri değiştirmekle ilgili bir olay oluşturur. Bu etkinliğe abone olan tüm görünümler (bu belirli verileri değiştirmek önemlidir) bu olayı alır ve arayüzlerindeki verileri günceller.
Web uygulamalarında işler biraz farklı düzenlenir. Temel teknik fark, istemcinin, sunucunun inisiyatifiyle sunucu tarafı mesajlarını alamamasıdır .
Bu nedenle, bir web uygulamasındaki denetleyici genellikle görünüme herhangi bir mesaj göndermez, ancak müşteriye teknik olarak yeni bir görünüm veya hatta yeni bir istemci uygulaması olan yeni bir sayfa verir (bir sayfa diğeri hakkında hiçbir şey bilmiyorsa). .
Şu anda, bu sorun aşağıdaki yaklaşımlar kullanılarak kısmen çözülmektedir:
- Önemli verilerdeki değişiklikler için sunucuyu düzenli olarak yoklama (dakikada bir veya daha fazla).
- WebSockets, bir istemcinin sunucu mesajlarına abone olmasına izin verir.
- Sunucu tarafından Web push bildirimleri.
- HTTP/2 protokolü, sunucunun istemciye mesaj göndermeyi başlatmasına izin verir.