Bölüm 7. MVC (Model-View-Controller) modeline giriş

Bu materyal, "Kurumsal Geliştirmeye Giriş" serisinin bir parçasıdır. Önceki makaleler:

• ağ hakkında
• yazılım mimarisi hakkında
• HTTP/HTTPS hakkında
• Maven'in temelleri hakkında
• servletler hakkında (basit bir web uygulaması yazmak)
• servlet kapsayıcıları hakkında

Bu yazıda MVC denen bir şeyi öğreneceğiz. MVC'nin ne olduğu hakkında konuşacağız, geçmişine değineceğiz, MVC'de yer alan temel fikir ve kavramları keşfedeceğiz, bir uygulamanın Model, Görünüm ve Denetleyici modüllerine nasıl bölüneceğine adım adım göz atacağız. Spring Boot kullanan küçük bir web uygulaması ve örnek olarak Spring MVC kullanarak, verilerin Java kodundan HTML sayfalarına nasıl gönderildiğini görün. Bu malzemeyi anlamak için, özellikle gözlemci ve cephe olmak üzere tasarım desenlerine aşina olmanız gerekir. HTTP isteklerine ve yanıtlarına aşina olun, HTML'nin temellerini anlayın ve Java ek açıklamalarının ne olduğunu öğrenin. Bir fincan kahve ve atıştırmalık alın ve rahatlayın. Hadi başlayalım.

MVC'nin Tarihçesi

MVC'nin arkasındaki fikirler, 1970'lerin sonlarında Xerox PARC'ta çalışırken Trygve Reenskaug tarafından formüle edildi. O günlerde bilgisayarlarla çalışmak, bir derece ve sürekli olarak ciltler dolusu belgeleme çalışması gerektiriyordu. Reenskaug tarafından bir grup çok güçlü geliştiriciyle birlikte çözülen görev, sıradan bir kullanıcının bilgisayarla etkileşimini basitleştirmekti. Bir yandan son derece basit ve anlaşılır, diğer yandan bilgisayarları ve karmaşık uygulamaları kontrol etmeyi mümkün kılacak araçlar yaratmak gerekiyordu. Reenskaug, "her yaştan çocuk için" bir dizüstü bilgisayar geliştiren bir ekip üzerinde çalıştı - Alan Kay liderliğinde Dynabook ve SmallTalk dili. Bu, dostane bir arayüz kavramlarının ortaya konduğu zamandı. Pek çok açıdan, Reenskaug ve ekibi tarafından yapılan çalışma, BT alanının gelişimini etkiledi. İşte doğrudan MVC için geçerli olmayan, ancak bu gelişmelerin önemini gösteren ilginç bir gerçek. Alan Kaysöz konusu, "'84'te Apple'a ilk geldiğimde, Mac çoktan piyasadaydı ve Newsweek benimle iletişime geçti ve Mac hakkında ne düşündüğümü sordu. Ben de, 'Mac yeterince iyi olan ilk kişisel bilgisayar' dedim. eleştirilmek.' 2007'de iPhone'u duyurduktan sonra bana getirip verdi ve 'Alan, bu eleştirilecek kadar iyi mi' dedi. Ben de 'Steve, bu boyutu bir tablet kadar yap, dünyaya hükmedeceksin' dedim." 3 yıl sonra, 27 Ocak 2010'da Apple, 9,7 inç diyagonal iPad'i piyasaya sürdü. Başka bir deyişle Steve Jobs, Alan Kay'in tavsiyesine neredeyse tamamen uydu. Reenskaug'un projesi 10 yıl sürdü. Ancak MVC ile ilgili ilk yayın 10 yıl sonra gün yüzüne çıktı. Yazılım mimarisi üzerine birçok kitap ve makalenin yazarı olan Martin Fowler, Smalltalk'ın çalışan bir sürümünü kullanarak MVC üzerinde çalıştığından bahseder. Orijinal kaynaktan MVC hakkında uzun süre bilgi bulunmadığından ve diğer birkaç nedenden dolayı, bu kavramın çok sayıda farklı yorumu ortaya çıktı. Sonuç olarak, birçok kişi MVC'yi bir tasarım modeli olarak kabul eder. Daha az yaygın olarak, MVC'ye bileşik bir model veya karmaşık uygulamalar oluşturmak için birlikte çalışan birkaç modelin bir kombinasyonu denir. Ancak, daha önce de belirtildiği gibi, MVC aslında öncelikle farklı kalıplar kullanılarak çeşitli şekillerde uygulanabilen bir dizi mimari fikir/ilke/yaklaşımdır... Şimdi, MVC konseptinde gömülü olan ana fikirleri ele alacağız. ve diğer birkaç nedenden dolayı, bu kavramın çok sayıda farklı yorumu ortaya çıktı. Sonuç olarak, birçok kişi MVC'yi bir tasarım modeli olarak kabul eder. Daha az yaygın olarak, MVC'ye bileşik bir model veya karmaşık uygulamalar oluşturmak için birlikte çalışan birkaç modelin bir kombinasyonu denir. Ancak, daha önce de belirtildiği gibi, MVC aslında öncelikle farklı kalıplar kullanılarak çeşitli şekillerde uygulanabilen bir dizi mimari fikir/ilke/yaklaşımdır... Şimdi, MVC konseptinde gömülü olan ana fikirleri ele alacağız. ve diğer birkaç nedenden dolayı, bu kavramın çok sayıda farklı yorumu ortaya çıktı. Sonuç olarak, birçok kişi MVC'yi bir tasarım modeli olarak kabul eder. Daha az yaygın olarak, MVC'ye bileşik bir model veya karmaşık uygulamalar oluşturmak için birlikte çalışan birkaç modelin bir kombinasyonu denir. Ancak, daha önce de belirtildiği gibi, MVC aslında öncelikle farklı kalıplar kullanılarak çeşitli şekillerde uygulanabilen bir dizi mimari fikir/ilke/yaklaşımdır... Şimdi, MVC konseptinde gömülü olan ana fikirleri ele alacağız.

MVC: Temel fikirler ve ilkeler

• VC, bir kullanıcı arayüzü ile karmaşık bilgi sistemleri oluşturmak için bir dizi mimari fikir ve ilkedir.
• MVC, şu anlama gelen bir kısaltmadır: Model-View-Controller

Yasal Uyarı: MVC bir tasarım deseni değildir. MVC, bir kullanıcı arabirimi ile karmaşık sistemler oluşturmak için bir dizi mimari fikir ve ilkedir . Ancak kolaylık sağlamak için, tekrar tekrar "bir dizi mimari fikir..." dememek için MVC modeline atıfta bulunacağız. Basit olanla başlayalım. Model-Görünüm-Denetleyici kelimelerinin arkasında ne gizli? Kullanıcı arabirimli sistemler geliştirmek için MVC modelini kullanırken, sistemi üç bileşene ayırmanız gerekir. Modüller veya bileşenler olarak da adlandırılabilirler. Onlara ne derseniz deyin, ancak sistemi üç bileşene ayırın. Her bileşenin kendi amacı vardır. modeli. İlk bileşen/modül model olarak adlandırılır. Uygulamanın tüm iş mantığını içerir. Görüş.Sistemin ikinci kısmı görünümdür. Bu modül, kullanıcıya verilerin gösterilmesinden sorumludur. Kullanıcının gördüğü her şey görünüm tarafından oluşturulur. Denetleyici.Bu zincirin üçüncü halkası denetleyicidir. Kullanıcı eylemlerinin işlenmesinden sorumlu olan kodu içerir (tüm kullanıcı eylemleri denetleyicide gerçekleştirilir). Model, sistemin en bağımsız parçasıdır. O kadar bağımsız ki, görünüm ve denetleyici modülleri hakkında hiçbir şey bilmemeli. Model o kadar bağımsız ki, geliştiricileri görünüm ve denetleyici hakkında neredeyse hiçbir şey bilmiyor olabilir. Görünümün temel amacı, modelden kullanıcının tüketebileceği bir biçimde bilgi sağlamaktır. Görünümün ana sınırlaması, modeli hiçbir şekilde değiştirmemesi gerektiğidir. Denetleyicinin temel amacı, kullanıcı işlemlerini gerçekleştirmektir. Kullanıcının modelde değişiklikler yapması denetleyici aracılığıyla gerçekleşir. Daha doğrusu modelde depolanan verilere. İşte daha önce derste gördüğünüz diyagram: Bütün bunlardan mantıklı bir sonuç çıkarabiliriz. Karmaşık bir sistemin modüllere bölünmesi gerekir. Bu ayrımı gerçekleştirmek için yapılması gereken adımları kısaca anlatalım.

Adım 1. Uygulamanın iş mantığını kullanıcı arabiriminden ayırın

MVC'nin ana fikri, kullanıcı arayüzü olan herhangi bir uygulamanın 2 modüle ayrılabilmesidir: iş mantığını uygulamaktan sorumlu bir modül ve kullanıcı arayüzü. İlk modül, uygulamanın ana işlevselliğini uygulayacaktır. Bu modül, uygulamanın etki alanı modelinin uygulandığı sistemin çekirdeğidir. MVC paradigmasında bu modül M harfi yani modeldir. İkinci modül, verileri kullanıcıya görüntüleme ve uygulama ile kullanıcı etkileşimini yönetme mantığı da dahil olmak üzere tüm kullanıcı arabirimini uygular. Bu ayrımın temel amacı, sistemin çekirdeğinin (MVC terminolojisindeki "model") bağımsız olarak geliştirilip test edilebilmesini sağlamaktır. Bu ayrımı yaptıktan sonra uygulamanın mimarisi şöyle görünür:

Adım 2 Modeli daha da bağımsız hale getirmek ve kullanıcı arayüzlerini senkronize etmek için gözlemci modelini kullanın

Burada 2 hedefimiz var:

1. Model için daha fazla bağımsızlık elde edin
2. Kullanıcı arayüzlerini senkronize edin

Aşağıdaki örnek, kullanıcı arayüzlerinin senkronizasyonu ile ne demek istediğimizi anlamanıza yardımcı olacaktır. Diyelim ki internetten bir sinema bileti alıyoruz ve sinemadaki boş koltuk sayısını görüyoruz. Aynı zamanda başka biri de sinema bileti alıyor olabilir. Bu kişi bizden önce bilet alırsa, düşündüğümüz gösteri zamanı için mevcut koltuk sayısında bir azalma görmek isteriz. Şimdi bunun bir program dahilinde nasıl uygulanabileceğini düşünelim. Sistemimizin çekirdeğine (modelimize) ve arayüzüne (bilet satın almak için web sayfası) sahip olduğumuzu varsayalım. İki kullanıcı aynı anda sinemada koltuk seçmeye çalışıyor. İlk kullanıcı bir bilet alır. Web sayfasının ikinci kullanıcıya bunun olduğunu göstermesi gerekiyor. Bunun nasıl olması gerekiyor? Arayüzü çekirdekten güncellersek, o zaman çekirdek (bizim modelimiz) arayüze bağlı olacaktır. Modeli geliştirip test ederken, arayüzü güncellemenin çeşitli yollarını aklımızda tutmamız gerekecek. Bunu başarmak için gözlemci modelini uygulamamız gerekiyor. Bu kalıp, modelin tüm dinleyicilere değişiklik bildirimleri göndermesini sağlar. Bir olay dinleyicisi (veya gözlemcisi) olarak, kullanıcı arayüzü bildirimleri alır ve güncellenir. Bir yandan, gözlemci modeli, modelin arayüze (görünüm ve denetleyici) değişikliklerin gerçekte hiçbir şey bilmeden gerçekleştiğini bildirmesini ve böylece bağımsız kalmasını sağlar. Öte yandan, kullanıcı arayüzlerini senkronize etmeyi mümkün kılar. gözlemci modelini uygulamamız gerekiyor. Bu kalıp, modelin tüm dinleyicilere değişiklik bildirimleri göndermesini sağlar. Bir olay dinleyicisi (veya gözlemcisi) olarak, kullanıcı arayüzü bildirimleri alır ve güncellenir. Bir yandan, gözlemci modeli, modelin arayüze (görünüm ve denetleyici) değişikliklerin gerçekte hiçbir şey bilmeden gerçekleştiğini bildirmesini ve böylece bağımsız kalmasını sağlar. Öte yandan, kullanıcı arayüzlerini senkronize etmeyi mümkün kılar. gözlemci modelini uygulamamız gerekiyor. Bu kalıp, modelin tüm dinleyicilere değişiklik bildirimleri göndermesini sağlar. Bir olay dinleyicisi (veya gözlemcisi) olarak, kullanıcı arayüzü bildirimleri alır ve güncellenir. Bir yandan, gözlemci modeli, modelin arayüze (görünüm ve denetleyici) değişikliklerin gerçekte hiçbir şey bilmeden gerçekleştiğini bildirmesini ve böylece bağımsız kalmasını sağlar. Öte yandan, kullanıcı arayüzlerini senkronize etmeyi mümkün kılar.

Adım 3 Arayüzü görünüm ve denetleyici olarak ayırın

Uygulamayı modüllere ayırmaya devam ediyoruz, ancak şimdi hiyerarşide daha düşük bir seviyede. Bu adımda, (1. adımda ayrı bir modüle ayırdığımız) kullanıcı arabirimi bir görünüme ve bir denetleyiciye ayrılır. Görünüm ve denetleyici arasında kesin bir çizgi çizmek zordur. Görünüm, kullanıcının gördüğü şeydir ve denetleyici, kullanıcının sistemle etkileşime girmesini sağlayan mekanizmadır dersek, bir çelişkiye işaret edebilirsiniz. Bir web sayfasındaki düğmeler veya bir telefonun ekranındaki sanal klavye gibi kontrol öğeleri temel olarak denetleyicinin bir parçasıdır. Ancak, kullanıcı tarafından görünümün herhangi bir parçası kadar görünürler. Burada gerçekten bahsettiğimiz şey işlevsel ayırmadır. Kullanıcı arayüzünün ana görevi, kullanıcının sistemle etkileşimini kolaylaştırmaktır.

• sistem bilgilerinin çıktısını alın ve kullanıcıya uygun şekilde görüntüleyin
• kullanıcı verilerini ve komutlarını girin (sisteme iletin)

Bu işlevler, kullanıcı arabiriminin modüllere nasıl bölünmesi gerektiğini belirler. Sonuçta sistem mimarisi şu şekilde görünüyor: Model, view ve controller adı verilen üç modülden oluşan bir uygulamaya bu şekilde ulaşmış oluyoruz. Özetleyelim:

1. MVC paradigmasının ilkelerine göre, bir sistem modüllere bölünmelidir.
2. En önemli ve bağımsız modül model olmalıdır.
3. Model, sistemin çekirdeğidir. Kullanıcı arayüzünden bağımsız olarak geliştirilip test edilebilmelidir.
4. Bunu başarmak için, bölmenin ilk adımında, sistemi bir modele ve kullanıcı arayüzüne ayırmamız gerekiyor.
5. Ardından, gözlemci modelini kullanarak modelin bağımsızlığını destekliyoruz ve kullanıcı arayüzlerini senkronize ediyoruz.
6. Üçüncü adım, kullanıcı arayüzünü bir denetleyiciye ve görünüme bölmek.
7. Kullanıcı verilerini sisteme almak için gereken her şey denetleyicidedir.
8. Kullanıcıya bilgi iletmek için gereken her şey görünümdedir.

Sıcak çikolatanızı içmeden önce konuşmanız gereken önemli bir şey daha var.

Görünümün ve denetleyicinin modelle nasıl etkileşime girdiği hakkında biraz

Kontrolör aracılığıyla bilgi girerek, kullanıcı modeli değiştirir. Veya en azından kullanıcı model verilerini değiştirir. Kullanıcı arabirim öğeleri aracılığıyla (görünüm aracılığıyla) bilgi aldığında, kullanıcı model hakkında bilgi alıyor demektir. Bu nasıl olur? Görünüm ve denetleyici modelle hangi yollarla etkileşime giriyor? Sonuçta, görünümün sınıfları, verileri okumak/yazmak için modelin sınıflarının yöntemlerini doğrudan çağıramaz. Aksi halde modelin bağımsız olduğunu söyleyemeyiz. Model, ne görünümün ne de denetleyicinin erişmesi gereken yakından ilişkili sınıflar kümesidir. Modeli görünüme ve denetleyiciye bağlamak için cephe tasarım modelini uygulamamız gerekir. Modelin cephesi, model ile kullanıcı arayüzü arasındaki katmandır, görünümün uygun biçimde biçimlendirilmiş verileri aldığı ve Denetleyicinin cephede gerekli yöntemleri çağırarak verileri değiştirdiği. Sonunda, her şey şöyle görünür:

MVC: Ne kazandık?

MVC paradigmasının temel amacı, iş mantığının uygulanmasını (model) görselleştirmesinden (görünüm) ayırmaktır. Bu ayırma, kodun yeniden kullanım olanaklarını artırır. MVC'nin faydaları, aynı verileri farklı formatlarda sunmamız gerektiğinde en belirgindir. Örneğin tablo, grafik veya tablo olarak (farklı görünümler kullanarak). Aynı zamanda, görünümlerin nasıl uygulandığını etkilemeden, kullanıcı eylemlerine (düğme tıklamaları, veri girişi) nasıl yanıt verdiğimizi değiştirebiliriz. MVC ilkelerini izlerseniz, yazılım geliştirmeyi basitleştirebilir, kod okunabilirliğini artırabilir ve genişletilebilirliği ve sürdürülebilirliği iyileştirebilirsiniz. "Kurumsal Geliştirmeye Giriş" serisinin son makalesinde, Spring MVC kullanılarak oluşturulmuş bir MVC uygulamasına bakacağız. Bölüm 8. Spring Boot kullanarak küçük bir uygulama yazalım