Sa materyal na ito ipapakilala namin sa iyo ang isang bagay tulad ng MVC. Pag-usapan natin kung ano ang MVC, pindutin ang kasaysayan ng paglikha nito, unawain ang mga pangunahing ideya at konsepto na likas sa MVC, isaalang-alang ang hakbang-hakbang kung paano hatiin ang isang application sa Model, View, Controller modules, at magsulat din ng maliit na web application sa Spring-Boot, at Paggamit ng Spring-MVC bilang isang halimbawa, tingnan natin kung paano inililipat ang data mula sa Java code patungo sa mga html na pahina. Upang maunawaan ang materyal na ito, kailangan mong maging pamilyar sa mga pattern ng disenyo, lalo na ang Observer at Facade. Maging pamilyar sa mga kahilingan at tugon ng HTTP, unawain ang mga pangunahing kaalaman ng html, alamin kung ano ang mga anotasyon sa Java. Umupo, gumawa ng tsaa, maghanda ng dessert, salad, pangunahing kurso at unang kurso. Magsisimula tayo.
Kasaysayan ng MVC
Ang mga ideya para sa MVC ay binuo ni Trygve Reenskaug habang nagtatrabaho sa Xerox PARC noong huling bahagi ng dekada 70. Noong mga panahong iyon, imposibleng magtrabaho sa isang computer nang walang akademikong degree at patuloy na pag-aaral ng napakaraming dokumentasyon. Ang problemang nalutas ni Reenskaug kasama ng isang grupo ng napakalakas na developer ay ang pasimplehin ang pakikipag-ugnayan ng karaniwang user sa isang computer. Kinailangan na lumikha ng mga tool na, sa isang banda, ay magiging sobrang simple at nauunawaan, at sa kabilang banda, gagawing posible na pamahalaan ang isang computer at kumplikadong mga application. Nagtrabaho si Reenskaug sa koponan na bumuo ng portable na computer "para sa mga bata sa lahat ng edad" - Dynabook, pati na rin ang wikang SmallTalk sa ilalim ng pamumuno ni Alan Kay. Noon at doon na inilatag ang mga konsepto ng isang friendly na interface. Ang trabaho ni Reenskaug kasama ang kanyang koponan ay lubos na nakaimpluwensya sa pag-unlad ng larangan ng IT. Ipakita natin ang isang kawili-wiling katotohanan na hindi direktang nauugnay sa MVC, ngunit inilalarawan ang kahalagahan ng mga pag-unlad na iyon. Noong 2007, pagkatapos ng pagtatanghal ng Apple iPhone, sinabi ni Alan Kay: "Nang lumabas ang Macintosh, tinanong ng Newsweek kung ano ang naisip ko dito. Sinabi ko: ito ang unang personal na computer na karapat-dapat sa pagpuna. Pagkatapos ng pagtatanghal, dumating si Steve Jobs at nagtanong: ang iPhone ba ay karapat-dapat sa pagpuna? At ang sabi ko, gawin mong five by eight inches and you will conquer the world.” Pagkalipas ng tatlong taon, noong Enero 27, 2010, ipinakilala ng Apple ang 9.7-pulgadang iPad. Ibig sabihin, halos literal na sinunod ni Steve Jobs ang payo ni Alan Kay. Ang proyektong pinaghirapan ni Rennskaug ay tumagal ng 10 taon. At ang unang publikasyon tungkol sa MVC mula sa mga tagalikha nito ay nai-publish isa pang 10 taon mamaya. Binanggit ni Martin Fowler, may-akda ng ilang libro at artikulo sa arkitektura ng software, na natutunan niya ang MVC mula sa gumaganang bersyon ng SmallTalk. Dahil walang impormasyon tungkol sa MVC mula sa pangunahing mapagkukunan sa loob ng mahabang panahon, pati na rin para sa maraming iba pang mga kadahilanan, isang malaking bilang ng iba't ibang mga interpretasyon ng konseptong ito ang lumitaw. Bilang resulta, itinuturing ng maraming tao ang MVC bilang isang scheme o pattern ng disenyo. Hindi gaanong karaniwan, ang MVC ay tinatawag na composite pattern o kumbinasyon ng ilang pattern na nagtutulungan upang ipatupad ang mga kumplikadong application. Ngunit sa katunayan, gaya ng sinabi kanina, ang MVC ay pangunahing isang hanay ng mga ideya/prinsipyo/diskarte sa arkitektura na maaaring ipatupad sa iba't ibang paraan gamit ang iba't ibang mga pattern... Susunod, susubukan nating tingnan ang mga pangunahing ideya na nakapaloob sa konsepto ng MVC.
Ano ang MVC: mga pangunahing ideya at prinsipyo
Ang VC ay isang hanay ng mga ideya at prinsipyo sa arkitektura para sa pagbuo ng mga kumplikadong sistema ng impormasyon na may user interface;
Ang MVC ay isang acronym na nangangahulugang Model-View-Controller.
Disclaimer: Ang MVC ay hindi isang pattern ng disenyo. Ang MVC ay tiyak na isang hanay ng mga ideya at prinsipyo sa arkitektura para sa pagbuo ng mga kumplikadong sistema na may user interface. Ngunit para sa kaginhawahan, upang hindi maulit sa bawat oras: "Isang hanay ng mga ideya sa arkitektura ...", tatawagin namin ang MVC na isang pattern. Magsimula tayo sa isang bagay na simple. Ano ang nakatago sa likod ng mga salitang Model-View-Controller? Kapag bumubuo ng mga system na may user interface, na sumusunod sa pattern ng MVC, kailangan mong hatiin ang system sa tatlong bahagi. Ang mga ito, sa turn, ay maaaring tawaging mga module o mga bahagi. Sabihin kung ano ang gusto mo, ngunit hatiin sa tatlo. Ang bawat bahagi ay magkakaroon ng sariling layunin. Modelo. Ang unang bahagi/module ay ang tinatawag na modelo. Naglalaman ito ng lahat ng lohika ng negosyo ng application. Tingnan. Ang pangalawang bahagi ng system ay ang view. Ang module na ito ay responsable para sa pagpapakita ng data sa user. Lahat ng nakikita ng user ay nabuo ng view. Controller. Ang pangatlong link sa chain na ito ay ang controller. Nag-iimbak ito ng code na responsable para sa pagproseso ng mga aksyon ng user (anumang pagkilos ng user sa system ay pinoproseso sa controller). Ang modelo ay ang pinaka-independiyenteng bahagi ng system. Napaka independyente na hindi ito dapat malaman tungkol sa mga module ng View at Controller. Ang modelo ay napaka-independiyente na ang mga developer nito ay maaaring halos walang alam tungkol sa View at Controller. Ang pangunahing layunin ng View ay upang magbigay ng impormasyon mula sa Modelo sa isang user-friendly na format. Ang pangunahing limitasyon ng View ay hindi nito dapat baguhin ang modelo sa anumang paraan. Ang pangunahing layunin ng Controller ay upang iproseso ang mga aksyon ng user. Ito ay sa pamamagitan ng Controller na ang user ay gumagawa ng mga pagbabago sa modelo. Mas tiyak, sa data na nakaimbak sa modelo. Ibigay natin muli ang diagram na ipinakita na sa iyo sa panayam: Mula sa lahat ng ito maaari tayong gumuhit ng isang ganap na lohikal na konklusyon. Ang isang kumplikadong sistema ay kailangang hatiin sa mga module. Ilarawan natin nang maikli ang mga hakbang kung paano makamit ang gayong paghihiwalay.
Hakbang 1: Ihiwalay ang lohika ng negosyo ng application mula sa user interface
Ang pangunahing ideya ng MVC ay ang anumang application na may user interface ay maaaring, sa unang pagtataya, ay nahahati sa 2 module: isang module na responsable para sa pagpapatupad ng business logic ng application, at isang user interface. Ipapatupad ng unang module ang pangunahing functionality ng application. Ang module na ito ang magiging core ng system, kung saan ipinatupad ang modelo ng domain ng application. Sa konsepto ng MVC, ang modyul na ito ay magiging ating titik M, i.e. modelo. Ipapatupad ng pangalawang module ang buong user interface, kabilang ang pagpapakita ng data sa user at ang lohika ng pakikipag-ugnayan ng user sa application. Ang pangunahing layunin ng paghihiwalay na ito ay upang matiyak na ang core ng system (Modelo sa terminolohiya ng MVC) ay maaaring independiyenteng mabuo at masuri. Ang arkitektura ng application pagkatapos ng naturang dibisyon ay magiging ganito:
Hakbang 2. Gamit ang pattern ng Observer, makamit ang mas higit na kalayaan ng modelo, pati na rin ang pag-synchronize ng mga user interface
Dito namin hinahabol ang 2 layunin:
Makamit ang mas higit na kalayaan ng modelo.
I-synchronize ang mga interface ng gumagamit.
Tutulungan ka ng sumusunod na halimbawa na maunawaan kung ano ang ibig sabihin ng pag-synchronize ng mga user interface. Sabihin nating bumili tayo ng tiket sa pelikula online at tingnan ang bilang ng mga available na upuan sa sinehan. May ibang makakabili ng movie ticket kasabay namin. Kung ito ay may bumili ng tiket bago sa amin, gusto naming makita na ang bilang ng mga magagamit na upuan para sa aming session ay nabawasan. Ngayon isipin natin kung paano ito maipapatupad sa loob ng programa. Ipagpalagay natin na mayroon tayong system core (aming modelo) at isang interface (ang web page kung saan tayo bumibili). Sa site, 2 user ang sabay na pumipili ng upuan. Bumili ng ticket ang unang user. Kailangang ipakita ng pangalawang user ang impormasyong ito sa page. Paano ito mangyayari? Kung i-update namin ang interface mula sa kernel ng system, ang aming kernel, ang aming modelo, ay nakasalalay sa interface. Kapag binubuo at sinusubukan ang modelo, kailangan mong isaisip ang iba't ibang paraan upang i-update ang interface. Upang makamit ito, kailangan mong ipatupad ang pattern ng Observer. Sa tulong nito, nagpapadala ang modelo ng mga notification tungkol sa mga pagbabago sa lahat ng subscriber. Ang interface, bilang isang subscriber, ay makakatanggap ng notification at update. Ang pattern ng Observer ay nagpapahintulot sa modelo, sa isang banda, na ipaalam sa interface (view at controller) na ang mga pagbabago ay naganap dito, at sa kabilang banda, upang aktwal na "alam" ng wala tungkol sa mga ito, at sa gayon ay mananatiling independyente. Sa kabilang banda, ito ay magbibigay-daan sa mga user interface na ma-synchronize.
Hakbang 3. Paghahati sa interface sa View at Controller
Patuloy naming hinahati ang application sa mga module, ngunit sa mas mababang antas ng hierarchy. Sa hakbang na ito, ang user interface (na pinaghiwalay sa isang hiwalay na module sa hakbang 1) ay nahahati sa isang view at isang controller. Mahirap gumuhit ng mahigpit na linya sa pagitan ng view at controller. Kung sasabihin natin na ang view ay kung ano ang nakikita ng user, at ang controller ay ang mekanismo kung saan maaaring makipag-ugnayan ang user sa system, mayroong ilang kontradiksyon. Ang mga kontrol, gaya ng mga button sa isang web page o isang virtual na keyboard sa screen ng telepono, ay mahalagang bahagi ng controller. Ngunit ang mga ito ay nakikita ng gumagamit tulad ng anumang bahagi ng view. Narito kami ay nagsasalita nang higit pa tungkol sa functional division. Ang pangunahing gawain ng user interface ay upang matiyak ang pakikipag-ugnayan ng user sa system. Nangangahulugan ito na ang interface ay may 2 function lamang:
ipakita at maginhawang ipakita ang impormasyon tungkol sa system sa user;
ipasok ang data ng user at mga utos sa system (ipadala ang mga ito sa system);
Tinutukoy ng mga function na ito kung paano dapat hatiin ang interface sa mga module. Bilang resulta, ganito ang hitsura ng arkitektura ng system: Kaya, mayroon kaming isang application ng tatlong module na tinatawag na Model, View at Controller. Upang ibuod:
Kasunod ng mga prinsipyo ng MVC, kailangang hatiin ang system sa mga module.
Ang pinakamahalaga at independiyenteng modyul ay dapat ang modelo.
Ang modelo ay ang core ng system. Kailangan mo ng kakayahang bumuo at subukan ito nang hiwalay sa interface.
Upang gawin ito, sa unang hakbang ng paghihiwalay ng system, kailangan mong hatiin ito sa isang modelo at isang interface.
Susunod, gamit ang pattern ng Observer, pinalalakas namin ang modelo sa pagsasarili nito at kumuha ng pag-synchronize ng mga interface ng gumagamit.
Ang ikatlong hakbang ay upang hatiin ang interface sa isang controller at isang view.
Ang lahat ng kailangan para magpasok ng impormasyon mula sa user sa system ay nasa controller.
Lahat ng naglalabas ng impormasyon mula sa system patungo sa user ay makikita.
May isa pang mahalagang bagay na dapat pag-usapan at maaari kang uminom ng kakaw.
Kaunti tungkol sa ugnayan sa pagitan ng View at ng Controller at ng Modelo
Kapag nagpasok ang user ng impormasyon sa pamamagitan ng controller, sa gayon ay gumagawa siya ng mga pagbabago sa modelo. Hindi bababa sa ang user ay gumagawa ng mga pagbabago sa data ng modelo. Kapag nakatanggap ang user ng impormasyon sa pamamagitan ng mga elemento ng interface (sa pamamagitan ng View), nakakatanggap ang user ng impormasyon tungkol sa data ng modelo. Paano ito nangyayari? Paano nakikipag-ugnayan ang View at Controller sa modelo? Pagkatapos ng lahat, hindi maaaring direktang gamitin ng mga klase ng View ang mga pamamaraan ng mga klase ng Modelo upang magbasa/magsulat ng data, kung hindi man ay maaaring walang tanong sa anumang kalayaan ng Modelo. Ang Modelo ay kumakatawan sa isang mahigpit na magkakaugnay na hanay ng mga klase kung saan, sa mabuting paraan, hindi dapat magkaroon ng access ang View o ang Controller. Upang ikonekta ang Modelo sa View at Controller, kinakailangan na ipatupad ang pattern ng disenyo ng Facade. Ang facade ng modelo ay ang mismong layer sa pagitan ng Modelo at ng interface, kung saan natatanggap ng View ang data sa isang maginhawang format, at binabago ng Controller ang data sa pamamagitan ng pagtawag sa mga kinakailangang pamamaraan ng facade. Sa eskematiko, sa huli, ang lahat ay magiging ganito:
MVC: ano ang pakinabang?
Ang pangunahing layunin ng pagsunod sa mga prinsipyo ng MVC ay ang paghiwalayin ang pagpapatupad ng business logic (modelo) ng application mula sa visualization nito (view). Ang paghihiwalay na ito ay magpapataas ng muling paggamit ng code. Ang mga benepisyo ng paggamit ng MVC ay pinaka-halata sa mga kaso kung saan ang user ay kailangang magbigay ng parehong data sa iba't ibang anyo. Halimbawa, sa anyo ng isang talahanayan, graph o tsart (gamit ang iba't ibang uri). Kasabay nito, nang hindi naaapektuhan ang pagpapatupad ng mga view, maaari mong baguhin ang mga reaksyon sa mga aksyon ng user (pag-click sa isang pindutan, pagpasok ng data). Kung susundin mo ang mga prinsipyo ng MVC, maaari mong pasimplehin ang pagsulat ng mga programa, pataasin ang pagiging madaling mabasa ng code, at gawing mas madali ang pagpapalawak at pagpapanatili ng system sa hinaharap. Sa huling materyal ng seryeng "Introduction to Enterprise Development", titingnan natin ang pagpapatupad ng MVC gamit ang Spring-MVC bilang isang halimbawa. Bahagi 8. Pagsusulat ng isang maliit na aplikasyon sa spring-boot
Mula sa lahat ng ito maaari tayong gumuhit ng isang ganap na lohikal na konklusyon. Ang isang kumplikadong sistema ay kailangang hatiin sa mga module. Ilarawan natin nang maikli ang mga hakbang kung paano makamit ang gayong paghihiwalay.
Kaya, mayroon kaming isang application ng tatlong module na tinatawag na Model, View at Controller. Upang ibuod:
GO TO FULL VERSION