Bu materialda sizi MVC kimi bir şeylə tanış edəcəyik. MVC-nin nə olduğu haqqında danışaq, onun yaranma tarixinə toxunaq, MVC-yə xas olan əsas ideyaları və konsepsiyaları anlayaq, tətbiqi Model, Görünüş, Nəzarətçi modullarına necə bölmək barədə addım-addım nəzərdən keçirək, həmçinin kiçik bir veb tətbiqi yazaq. Spring-Boot və Spring-MVC-dən nümunə kimi istifadə edərək verilənlərin Java kodundan html səhifələrinə necə ötürüldüyünə baxaq. Bu materialı başa düşmək üçün dizayn nümunələri, xüsusən Observer və Fasad ilə tanış olmaq lazımdır. HTTP sorğuları və cavabları ilə tanış olun, html əsaslarını anlayın, Java-da hansı annotasiyaların olduğunu bilin. Arxaya oturun, çay hazırlayın, desert, salat, əsas yemək və birinci yemək hazırlayın. Başlayırıq.
MVC-nin tarixi
MVC üçün ideyalar 70-ci illərin sonlarında Xerox PARC-də işləyərkən Trygve Reenskaug tərəfindən tərtib edilmişdir. O günlərdə kompüterlə işləmək elmi dərəcə olmadan və həcmli sənədləri daim öyrənmədən mümkün deyildi. Reenskauqun çox güclü tərtibatçılar qrupu ilə birlikdə həll etdiyi problem orta istifadəçinin kompüterlə qarşılıqlı əlaqəsini sadələşdirmək idi. Bir tərəfdən son dərəcə sadə və başa düşülən, digər tərəfdən isə kompüteri və mürəkkəb proqramları idarə etməyə imkan verən alətlər yaratmaq lazım idi. Reenskaug, Alan Kayın rəhbərliyi altında "bütün yaşda olan uşaqlar üçün" portativ kompüteri - Dynabook, eləcə də SmallTalk dilini hazırlayan komandada çalışdı. Məhz o zaman və orada dostluq interfeysi anlayışları qoyuldu. Reenskauqun komandası ilə işləməsi İT sahəsinin inkişafına böyük təsir göstərmişdir. MVC-yə birbaşa aidiyyatı olmayan, lakin həmin inkişafların əhəmiyyətini göstərən maraqlı bir faktı təqdim edək. 2007-ci ildə Apple iPhone-un təqdimatından sonra Alan Kay demişdi: “Makintoş çıxanda Newsweek onun haqqında nə düşündüyümü soruşdu. Dedim: bu, tənqidə layiq ilk fərdi kompüterdir. Təqdimatdan sonra Stiv Cobs gündəmə gəldi və soruşdu: iPhone tənqidə layiqdirmi? Mən də dedim ki, onu beşə səkkiz düym düzəldin və dünyanı fəth edəcəksiniz”. Üç il sonra, 27 yanvar 2010-cu ildə Apple 9,7 düymlük iPad-i təqdim etdi. Yəni Stiv Cobs Alan Kayın məsləhətinə demək olar ki, sözün əsl mənasında əməl edirdi. Rennskauqun üzərində çalışdığı layihə 10 il davam etdi. Və yaradıcılarından MVC haqqında ilk nəşr daha 10 il sonra nəşr olundu. Proqram təminatının arxitekturasına dair bir sıra kitab və məqalələrin müəllifi Martin Fowler MVC-ni SmallTalk proqramının işlək versiyasından öyrəndiyini qeyd edir. Uzun müddətdir MVC haqqında ilkin mənbədən məlumat olmadığından, eləcə də bir sıra digər səbəblərdən bu konsepsiyanın çoxlu sayda müxtəlif şərhləri ortaya çıxdı. Nəticədə bir çox insanlar MVC-ni dizayn sxemi və ya nümunəsi hesab edirlər. Daha az yaygın olaraq, MVC mürəkkəb tətbiqləri həyata keçirmək üçün birlikdə işləyən birləşdirilmiş nümunə və ya bir neçə nümunənin birləşməsi adlanır. Amma əslində, əvvəllər deyildiyi kimi, MVC, ilk növbədə, müxtəlif naxışlardan istifadə etməklə müxtəlif yollarla həyata keçirilə bilən memarlıq ideyaları/prinsipləri/yanaşmaları toplusudur... Sonra, MVC konsepsiyasına daxil edilmiş əsas ideyalara nəzər salmağa çalışacağıq.
MVC nədir: əsas ideyalar və prinsiplər
VC istifadəçi interfeysi ilə mürəkkəb informasiya sistemlərinin qurulması üçün memarlıq ideyaları və prinsipləri toplusudur;
MVC, Model-View-Controller mənasını verən qısaltmadır.
İmtina: MVC dizayn nümunəsi deyil. MVC dəqiq istifadəçi interfeysi ilə mürəkkəb sistemlərin qurulması üçün memarlıq ideyaları və prinsipləri toplusudur . Ancaq rahatlıq üçün hər dəfə təkrarlamamaq üçün: “Memarlıq ideyaları toplusu...” MVC-ni nümunə adlandıracağıq. Sadə bir şeylə başlayaq. Model-View-Controller sözlərinin arxasında nə gizlənir? MVC modelinə uyğun olaraq istifadəçi interfeysi olan sistemlər hazırlayarkən sistemi üç komponentə bölmək lazımdır. Bunları da öz növbəsində modullar və ya komponentlər adlandırmaq olar. İstədiyinizi söyləyin, ancaq üçə bölün. Hər bir komponentin öz məqsədi olacaq. Model. Birinci komponent/modul sözdə modeldir. Tətbiqin bütün iş məntiqini ehtiva edir. Baxın. Sistemin ikinci hissəsi görünüşdür. Bu modul məlumatların istifadəçiyə göstərilməsinə cavabdehdir. İstifadəçinin gördüyü hər şey görünüş tərəfindən yaradılır. Nəzarətçi. Bu zəncirin üçüncü halqası nəzarətçidir. O, istifadəçi hərəkətlərinin işlənməsi üçün cavabdeh olan kodu saxlayır (sistemdəki istənilən istifadəçi hərəkəti nəzarətçidə emal olunur). Model sistemin ən müstəqil hissəsidir. O qədər müstəqildir ki, View və Controller modulları haqqında heç nə bilməməlidir. Model o qədər müstəqildir ki, onu tərtib edənlər View və Controller haqqında praktiki olaraq heç nə bilmirlər. Görünüşün əsas məqsədi Modeldən məlumatı istifadəçi üçün əlverişli formatda təqdim etməkdir. Görünüşün əsas məhdudiyyəti modeli heç bir şəkildə dəyişdirməməsidir. Nəzarətçinin əsas məqsədi istifadəçi hərəkətlərini emal etməkdir. Nəzarətçi vasitəsilə istifadəçi modelə dəyişikliklər edir. Daha doğrusu, modeldə saxlanılan məlumatlara. Artıq mühazirədə sizə göstərilən diaqramı bir daha verək: Bütün bunlardan tamamilə məntiqi nəticə çıxara bilərik. Mürəkkəb bir sistemi modullara bölmək lazımdır. Belə bir ayrılığa necə nail olmaq üçün addımları qısaca təsvir edək.
Addım 1: Tətbiqin iş məntiqini istifadəçi interfeysindən ayırın
MVC-nin əsas ideyası ondan ibarətdir ki, istifadəçi interfeysi olan hər hansı bir proqram, ilk təqribən, 2 modula bölünə bilər: tətbiqin iş məntiqini həyata keçirmək üçün məsul olan modul və istifadəçi interfeysi. Birinci modul proqramın əsas funksionallığını həyata keçirəcək. Bu modul proqram domeni modelinin tətbiq olunduğu sistemin əsasını təşkil edəcək. MVC konsepsiyasında bu modul bizim M hərfimiz olacaq, yəni. model. İkinci modul bütün istifadəçi interfeysini, o cümlədən məlumatların istifadəçiyə göstərilməsi və istifadəçinin proqramla qarşılıqlı əlaqəsinin məntiqini həyata keçirəcək. Bu ayırmanın əsas məqsədi sistemin nüvəsinin (MVC terminologiyasındakı model) müstəqil şəkildə işlənib sınaqdan keçirilməsini təmin etməkdir. Belə bir bölmədən sonra tətbiq arxitekturası belə görünəcək:
Addım 2. Müşahidəçi nümunəsindən istifadə edərək, modelin daha böyük müstəqilliyinə, həmçinin istifadəçi interfeyslərinin sinxronizasiyasına nail olun
Burada 2 hədəfimiz var:
Modelin daha böyük müstəqilliyinə nail olun.
İstifadəçi interfeyslərini sinxronlaşdırın.
Aşağıdakı nümunə istifadəçi interfeyslərinin sinxronlaşdırılması ilə nə demək olduğunu başa düşməyə kömək edəcək. Deyək ki, onlayn kino bileti alırıq və teatrda mövcud yerlərin sayını görürük. Bizimlə eyni vaxtda başqası kino bileti ala bilər. Əgər bu kimsə bizdən əvvəl bilet alsa, sessiyamız üçün mövcud yerlərin sayının azaldığını görmək istərdik. İndi gəlin bunun proqram daxilində necə həyata keçirilə biləcəyini düşünək. Tutaq ki, bizim sistem nüvəmiz (modelimiz) və interfeysimiz (alış-veriş etdiyimiz veb səhifə). Saytda 2 istifadəçi eyni vaxtda oturacaq seçir. İlk istifadəçi bilet alıb. İkinci istifadəçi bu məlumatı səhifədə göstərməlidir. Bu necə baş verməlidir? Sistem nüvəsindən interfeysi yeniləsək, nüvəmiz, modelimiz interfeysdən asılı olacaq. Modeli hazırlayarkən və sınaqdan keçirərkən interfeysi yeniləməyin müxtəlif yollarını yadda saxlamalı olacaqsınız. Buna nail olmaq üçün Observer modelini tətbiq etməlisiniz. Onun köməyi ilə model bütün abunəçilərə dəyişikliklər barədə bildirişlər göndərir. Belə bir abunəçi olan interfeys bildiriş və yeniləmə alacaq. Observer modeli bir tərəfdən modelə interfeysə (görünüş və nəzarətçi) onda baş verən dəyişikliklər barədə məlumat verməyə, digər tərəfdən isə onlar haqqında əslində heç nə “bilməyə” və bununla da müstəqil qalmağa imkan verir. Digər tərəfdən, bu, istifadəçi interfeyslərinin sinxronizasiyasına imkan verəcək.
Addım 3. İnterfeysi View və Controller-ə bölmək
Tətbiqi modullara bölməyə davam edirik, lakin iyerarxiyanın daha aşağı səviyyəsində. Bu addımda istifadəçi interfeysi (1-ci addımda ayrıca modula ayrılmışdır) görünüşə və nəzarətçiyə bölünür. Görünüş və nəzarətçi arasında ciddi bir xətt çəkmək çətindir. Baxış istifadəçinin gördüyü şeydir, nəzarətçi isə istifadəçinin sistemlə qarşılıqlı əlaqə qura biləcəyi mexanizmdir desək, müəyyən ziddiyyət yaranır. Veb səhifədəki düymələr və ya telefon ekranındakı virtual klaviatura kimi idarəetmə elementləri əslində nəzarətçinin bir hissəsidir. Lakin onlar istifadəçiyə görünüşün hər hansı bir hissəsi kimi görünür. Burada daha çox funksional bölgüdən danışırıq. İstifadəçi interfeysinin əsas vəzifəsi istifadəçinin sistemlə qarşılıqlı əlaqəsini təmin etməkdir. Bu o deməkdir ki, interfeys yalnız 2 funksiyaya malikdir:
sistem haqqında məlumatları istifadəçiyə göstərmək və rahat şəkildə göstərmək;
istifadəçi məlumatlarını və əmrləri sistemə daxil etmək (onları sistemə ötürmək);
Bu funksiyalar interfeysin modullara necə bölünməsini müəyyən edir. Nəticədə sistemin arxitekturası belə görünür: Beləliklə, Model, Görünüş və Nəzarətçi adlı üç moduldan ibarət tətbiqimiz var. Xülasə etmək üçün:
MVC prinsiplərinə uyğun olaraq sistemi modullara bölmək lazımdır.
Ən vacib və müstəqil modul model olmalıdır.
Model sistemin əsasını təşkil edir. Siz onu interfeysdən asılı olmayaraq inkişaf etdirmək və sınaqdan keçirmək qabiliyyətinə ehtiyacınız var.
Bunun üçün sistemin seqreqasiyasının ilk addımında onu modelə və interfeysə bölmək lazımdır.
Sonra, Observer modelindən istifadə edərək, modeli müstəqilliyində gücləndiririk və istifadəçi interfeyslərinin sinxronizasiyasını əldə edirik.
Üçüncü addım interfeysi nəzarətçi və görünüşə bölməkdir.
İstifadəçidən sistemə məlumat daxil etmək üçün tələb olunanların hamısı nəzarətçiyə daxil olmaqdır.
Sistemdən istifadəçiyə məlumat verən hər şey göz qabağındadır.
Müzakirə ediləcək daha vacib bir şey var və kakao içə bilərsiniz.
Görünüş və Nəzarətçi və Model arasındakı əlaqə haqqında bir az
İstifadəçi nəzarətçi vasitəsilə məlumat daxil etdikdə, bununla da modeldə dəyişikliklər edir. Ən azı istifadəçi model məlumatlarında dəyişiklik edir. İstifadəçi interfeys elementləri vasitəsilə (Görünüş vasitəsilə) məlumat aldıqda, istifadəçi model məlumatları haqqında məlumat alır. Bu necə baş verir? Görünüş və Nəzarətçi modellə necə qarşılıqlı əlaqədə olur? Axı, ola bilməz ki, View sinifləri verilənləri oxumaq/yazmaq üçün birbaşa Model siniflərinin metodlarından istifadə etsin, əks halda Modelin müstəqilliyindən söhbət gedə bilməz. Model, yaxşı mənada, nə Görünüşün, nə də Nəzarətçinin girişi olmayan bir-biri ilə sıx əlaqəli siniflər toplusunu təmsil edir. Modeli Görünüş və Nəzarətçi ilə birləşdirmək üçün Fasad dizayn nümunəsini həyata keçirmək lazımdır. Modelin fasadı Model və interfeys arasında olan təbəqə olacaq, onun vasitəsilə View məlumatları rahat formatda qəbul edir, Nəzarətçi isə lazımi fasad üsullarını çağıraraq məlumatları dəyişir. Sxematik olaraq, sonda hər şey belə görünəcək:
MVC: faydası nədir?
MVC prinsiplərinə əməl etməyin əsas məqsədi tətbiqin biznes məntiqinin (modelinin) həyata keçirilməsini onun vizuallaşdırılmasından (görünüşündən) ayırmaqdır. Bu ayırma kodun təkrar istifadəsini artıracaq. MVC-dən istifadənin faydaları istifadəçinin eyni məlumatları müxtəlif formalarda təqdim etməli olduğu hallarda daha aydın görünür. Məsələn, cədvəl, qrafik və ya diaqram şəklində (müxtəlif növlərdən istifadə etməklə). Eyni zamanda, baxışların həyata keçirilməsinə təsir etmədən, istifadəçi hərəkətlərinə reaksiyaları dəyişə bilərsiniz (bir düyməni basmaq, məlumatların daxil edilməsi). MVC prinsiplərinə əməl etsəniz, proqramların yazılmasını sadələşdirə, kodun oxunaqlılığını artıra və gələcəkdə sistemin genişləndirilməsini və saxlanmasını asanlaşdıra bilərsiniz. “Müəssisələrin İnkişafına Giriş” seriyasının yekun materialında nümunə kimi Spring-MVC-dən istifadə edərək MVC-nin həyata keçirilməsinə baxacağıq. Part 8. Spring-boot-da kiçik proqramın yazılması
Bütün bunlardan tamamilə məntiqi nəticə çıxara bilərik. Mürəkkəb bir sistemi modullara bölmək lazımdır. Belə bir ayrılığa necə nail olmaq üçün addımları qısaca təsvir edək.
Beləliklə, Model, Görünüş və Nəzarətçi adlı üç moduldan ibarət tətbiqimiz var. Xülasə etmək üçün:
GO TO FULL VERSION