Sa artikulong ito, malalaman natin ang isang bagay na tinatawag na MVC. Pag-uusapan natin kung ano ang MVC, hipuin ang kasaysayan nito, tuklasin ang mga pangunahing ideya at konsepto na nakapaloob sa MVC, tingnan ang hakbang-hakbang kung paano hatiin ang isang application sa mga module ng Model, View, at Controller, magsulat ng isang maliit na web application gamit ang Spring Boot, at, gamit ang Spring MVC bilang isang halimbawa, tingnan kung paano ipinapadala 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 tagamasid at harapan. At maging pamilyar sa mga kahilingan at tugon ng HTTP, unawain ang mga pangunahing kaalaman ng HTML, at alamin kung ano ang mga anotasyon ng Java. Kumuha ng isang tasa ng kape at meryenda, at maging komportable. Magsimula tayo.
Kasaysayan ng MVC
Ang mga ideya sa likod ng MVC ay binuo ni Trygve Reenskaug habang nagtatrabaho sa Xerox PARC noong huling bahagi ng 1970s. Sa mga araw na iyon, ang pagtatrabaho sa mga computer ay nangangailangan ng isang degree at patuloy na pag-aaral ng napakaraming dokumentasyon. Ang gawaing nalutas ni Reenskaug kasama ang isang grupo ng napakalakas na developer ay ang pasimplehin ang pakikipag-ugnayan ng isang ordinaryong user sa computer. Kinailangan na lumikha ng mga tool na, sa isang banda, ay magiging sobrang simple at naiintindihan, at sa kabilang banda, gagawing posible na kontrolin ang mga computer at kumplikadong mga application. Nagtrabaho si Reenskaug sa isang team na bumuo ng laptop computer "para sa mga bata sa lahat ng edad" — ang Dynabook, pati na rin ang SmallTalk na wika sa ilalim ng pamumuno ni Alan Kay. Iyon ay kapag ang mga konsepto ng isang friendly na interface ay inilatag. Sa maraming aspeto, ang gawaing ginawa ni Reenskaug at ng kanyang koponan ay nakaimpluwensya sa ebolusyon ng IT sphere. Narito ang isang kawili-wiling katotohanan na hindi direktang naaangkop sa MVC, ngunit inilalarawan ang kahalagahan ng mga pag-unlad na ito. Alan Kaysabi, "Noong una akong nakarating sa Apple, na noong '84, nakalabas na ang Mac at nakipag-ugnayan sa akin ang Newsweek at tinanong ako kung ano ang tingin ko sa Mac. Sabi ko, 'Buweno, ang Mac ang unang personal na computer na sapat na mapintasan.' Kaya, pagkatapos ianunsyo ang iPhone noong 2007, dinala niya ito sa akin at ibinigay sa akin. Sabi niya, 'Alan, sapat na ba ito para punahin?' At sinabi ko, 'Steve, gawin itong kasing laki ng isang tablet at mamamahala ka sa mundo.'" Pagkalipas ng 3 taon, noong Enero 27, 2010, ipinakilala ng Apple ang iPad na may diagonal na 9.7 pulgada. Sa madaling salita, halos eksaktong sinunod ni Steve Jobs ang payo ni Alan Kay. Ang proyekto ni Reenskaug ay tumagal ng 10 taon. Ngunit ang unang publikasyon tungkol sa MVC ay nahayag pagkatapos ng isa pang 10 taon. Martin Fowler, may-akda ng ilang mga libro at artikulo sa arkitektura ng software, binanggit na nag-aral siya ng MVC gamit ang isang gumaganang bersyon ng Smalltalk. Dahil walang impormasyon tungkol sa MVC mula sa orihinal na pinagmulan sa loob ng mahabang panahon, at para sa ilang iba pang mga kadahilanan, isang malaking bilang ng iba't ibang mga interpretasyon ng konseptong ito ang lumitaw. Bilang resulta, itinuturing ng marami ang MVC bilang isang pattern ng disenyo. Hindi gaanong karaniwan, ang MVC ay tinatawag na isang composite pattern o isang kumbinasyon ng ilang mga pattern na nagtutulungan upang lumikha ng mga kumplikadong application. Ngunit, gaya ng nabanggit kanina, ang MVC ay talagang pangunahing isang hanay ng mga ideya/prinsipyo/diskarte sa arkitektura na maaaring ipatupad sa iba't ibang paraan gamit ang iba't ibang pattern... Susunod, isasaalang-alang natin ang mga pangunahing ideya na naka-embed sa konsepto ng MVC. at para sa ilang iba pang mga kadahilanan, isang malaking bilang ng iba't ibang mga interpretasyon ng konseptong ito ay lumitaw. Bilang resulta, itinuturing ng marami ang MVC bilang isang pattern ng disenyo. Hindi gaanong karaniwan, ang MVC ay tinatawag na isang composite pattern o isang kumbinasyon ng ilang mga pattern na nagtutulungan upang lumikha ng mga kumplikadong application. Ngunit, gaya ng nabanggit kanina, ang MVC ay talagang pangunahing isang hanay ng mga ideya/prinsipyo/diskarte sa arkitektura na maaaring ipatupad sa iba't ibang paraan gamit ang iba't ibang pattern... Susunod, isasaalang-alang natin ang mga pangunahing ideya na naka-embed sa konsepto ng MVC. at para sa ilang iba pang mga kadahilanan, isang malaking bilang ng iba't ibang mga interpretasyon ng konseptong ito ay lumitaw. Bilang resulta, itinuturing ng marami ang MVC bilang isang pattern ng disenyo. Hindi gaanong karaniwan, ang MVC ay tinatawag na isang composite pattern o isang kumbinasyon ng ilang mga pattern na nagtutulungan upang lumikha ng mga kumplikadong application. Ngunit, gaya ng nabanggit kanina, ang MVC ay talagang pangunahing isang hanay ng mga ideya/prinsipyo/diskarte sa arkitektura na maaaring ipatupad sa iba't ibang paraan gamit ang iba't ibang pattern... Susunod, isasaalang-alang natin ang mga pangunahing ideya na naka-embed sa konsepto ng MVC.
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 abbreviation na nangangahulugang: Model-View-Controller
Disclaimer: Ang MVC ay hindi isang pattern ng disenyo. Ang MVC ay 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 paulit-ulit na sabihin ang "isang hanay ng mga ideya sa arkitektura...", sasangguni kami sa pattern ng MVC. Magsimula tayo sa simple. Ano ang nakatago sa likod ng mga salitang Model-View-Controller? Kapag ginagamit ang pattern ng MVC upang bumuo ng mga system na may user interface, kailangan mong hatiin ang system sa tatlong bahagi. Maaari din silang tawaging mga module o mga bahagi. Tawagan sila kung ano ang gusto mo, ngunit hatiin ang system sa tatlong bahagi. Ang bawat bahagi ay may sariling layunin. Modelo. Ang unang bahagi/modyul ay 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. Naglalaman ito ng code na responsable para sa paghawak ng mga aksyon ng user (lahat ng pagkilos ng user ay pinangangasiwaan sa controller). Ang modelo ay ang pinaka-independiyenteng bahagi ng system. Napaka independiyente na hindi ito dapat malaman tungkol sa view at controller modules. 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 magbigay ng impormasyon mula sa modelo sa isang format na maaaring gamitin ng user. Ang pangunahing limitasyon ng view ay hindi nito dapat baguhin ang modelo sa anumang paraan. Ang pangunahing layunin ng controller ay upang pangasiwaan ang mga aksyon ng user. Ito ay sa pamamagitan ng controller na ang gumagamit ay gumagawa ng mga pagbabago sa modelo. O mas tiyak, sa data na nakaimbak sa modelo. Narito ang diagram na nakita mo dati sa aralin: Mula sa lahat ng ito, maaari tayong gumuhit ng isang lohikal na konklusyon. Ang isang kumplikadong sistema ay kailangang hatiin sa mga module. Ilarawan natin nang maikli ang mga hakbang upang makamit ang paghihiwalay na ito.
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 nahahati sa 2 module: isang module na responsable para sa pagpapatupad ng business logic, at ang user interface. Ipapatupad ng unang module ang pangunahing functionality ng application. Ang module na ito ay ang core ng system, kung saan ipinatupad ang modelo ng domain ng application. Sa paradigm ng MVC, ang modyul na ito ay ang titik M, ibig sabihin, ang modelo. Ang pangalawang module ay nagpapatupad ng buong user interface, kabilang ang logic upang ipakita ang data sa user at pangasiwaan ang pakikipag-ugnayan ng user sa application. Ang pangunahing layunin ng paghihiwalay na ito ay upang matiyak na ang core ng system (ang "modelo" sa terminolohiya ng MVC) ay maaaring independiyenteng mabuo at masuri. Pagkatapos gawin ang paghihiwalay na ito, ganito ang hitsura ng arkitektura ng application:
Hakbang 2 Gamitin ang pattern ng tagamasid upang gawing mas independyente ang modelo at upang i-synchronize ang mga interface ng gumagamit
Narito mayroon kaming 2 layunin:
Makamit ang mas higit na kalayaan para sa modelo
I-synchronize ang mga interface ng gumagamit
Tutulungan ka ng sumusunod na halimbawa na maunawaan kung ano ang ibig naming sabihin sa pag-synchronize ng mga user interface. Ipagpalagay na tayo ay bibili ng tiket sa pelikula online at makita ang bilang ng mga magagamit na upuan sa sinehan. Kasabay nito, maaaring may bumibili ng tiket sa pelikula. Kung ang ibang taong ito ay bibili ng tiket bago sa amin, gusto naming makita ang pagbaba sa bilang ng mga upuan na magagamit para sa oras ng palabas na aming isinasaalang-alang. Ngayon isipin natin kung paano ito maipapatupad sa loob ng isang programa. Ipagpalagay na mayroon kaming core ng aming system (ang aming modelo) at interface (ang web page para sa pagbili ng mga tiket). Dalawang user ang sumusubok na pumili ng upuan sa teatro nang sabay-sabay. Ang unang gumagamit ay bumili ng tiket. Kailangang ipakita ng web page sa pangalawang user na nangyari ito. Paano ito mangyayari? Kung i-update namin ang interface mula sa core, pagkatapos ay ang core (aming modelo) ay nakasalalay sa interface. Habang binubuo at sinusubok natin ang modelo, kailangan nating isaisip ang iba't ibang paraan ng pag-update ng interface. Upang makamit ito, kailangan nating ipatupad ang pattern ng tagamasid. Ang pattern na ito ay nagbibigay-daan sa modelo na magpadala ng mga abiso ng pagbabago sa lahat ng mga tagapakinig. Bilang isang tagapakinig ng kaganapan (o tagamasid), ang user interface ay tumatanggap ng mga abiso at ina-update. Sa isang banda, ang pattern ng tagamasid ay nagbibigay-daan sa modelo na ipaalam sa interface (view at controller) na ang mga pagbabago ay naganap nang walang aktwal na nalalaman tungkol dito, kaya nananatiling independyente. Sa kabilang banda, ginagawang posible na i-synchronize ang mga interface ng gumagamit. kailangan nating ipatupad ang pattern ng tagamasid. Ang pattern na ito ay nagbibigay-daan sa modelo na magpadala ng mga abiso ng pagbabago sa lahat ng mga tagapakinig. Bilang isang tagapakinig ng kaganapan (o tagamasid), ang user interface ay tumatanggap ng mga abiso at ina-update. Sa isang banda, ang pattern ng tagamasid ay nagbibigay-daan sa modelo na ipaalam sa interface (view at controller) na ang mga pagbabago ay naganap nang walang aktwal na nalalaman tungkol dito, kaya nananatiling independyente. Sa kabilang banda, ginagawang posible na i-synchronize ang mga interface ng gumagamit. kailangan nating ipatupad ang pattern ng tagamasid. Ang pattern na ito ay nagbibigay-daan sa modelo na magpadala ng mga abiso ng pagbabago sa lahat ng mga tagapakinig. Bilang isang tagapakinig ng kaganapan (o tagamasid), ang user interface ay tumatanggap ng mga abiso at ina-update. Sa isang banda, ang pattern ng tagamasid ay nagbibigay-daan sa modelo na ipaalam sa interface (view at controller) na ang mga pagbabago ay naganap nang walang aktwal na nalalaman tungkol dito, kaya nananatiling independyente. Sa kabilang banda, ginagawang posible na i-synchronize ang mga interface ng gumagamit.
Hakbang 3 Paghiwalayin ang interface sa view at controller
Patuloy naming hinahati ang application sa mga module, ngunit ngayon ay nasa mas mababang antas sa hierarchy. Sa hakbang na ito, ang user interface (na pinaghiwalay namin sa isang natatanging module sa hakbang 1) ay nahahati sa isang view at isang controller. Ang pagguhit ng isang mahigpit na linya sa pagitan ng view at ng controller ay mahirap. Kung sasabihin namin na ang view ay kung ano ang nakikita ng user, at ang controller ay ang mekanismo na nagpapahintulot sa user na makipag-ugnayan sa system, maaari mong ituro ang isang kontradiksyon. Ang mga elemento ng kontrol, gaya ng mga button sa isang web page o isang virtual na keyboard sa screen ng telepono, ay karaniwang bahagi ng controller. Ngunit nakikita ng user ang mga ito gaya ng anumang bahagi ng view. Ang talagang pinag-uusapan natin dito ay functional separation. Ang pangunahing gawain ng user interface ay upang mapadali ang pakikipag-ugnayan ng user sa system.
output at maginhawang ipakita ang impormasyon ng system sa user
ipasok ang data ng user at mga utos (ipaalam ang mga ito sa system)
Tinutukoy ng mga function na ito kung paano dapat hatiin ang user interface sa mga module. Sa huli, ganito ang hitsura ng arkitektura ng system: At ganito tayo nakarating sa isang application na binubuo ng tatlong module na tinatawag na model, view at controller. Ibuod natin:
Ayon sa mga prinsipyo ng paradigm ng MVC, ang isang sistema ay dapat nahahati sa mga module.
Ang pinakamahalaga at independiyenteng modyul ay dapat ang modelo.
Ang modelo ay ang core ng system. Ito ay dapat na posible na bumuo at subukan ito nang nakapag-iisa mula sa user interface.
Upang makamit ito, sa unang hakbang ng paghahati, kailangan nating hatiin ang system sa isang modelo at user interface.
Pagkatapos, gamit ang pattern ng tagamasid, pinalalakas namin ang kalayaan ng modelo at sini-synchronize namin ang mga interface ng gumagamit.
Ang ikatlong hakbang ay upang hatiin ang user interface sa isang controller at view.
Ang lahat ng kailangan para matanggap ang data ng user sa system ay nasa controller.
Ang lahat ng kailangan para sa paghahatid ng impormasyon sa user ay nasa view.
Isa lang ang mas mahalagang bagay na pag-usapan bago mo maiinom ang iyong mainit na tsokolate.
Kaunti tungkol sa kung paano nakikipag-ugnayan ang view at controller sa modelo
Sa pamamagitan ng pagpasok ng impormasyon sa pamamagitan ng controller, binabago ng user ang modelo. O hindi bababa sa, binago ng user ang data ng modelo. Kapag ang user ay nakatanggap ng impormasyon sa pamamagitan ng mga elemento ng interface (sa pamamagitan ng view), ang user ay tumatanggap ng impormasyon tungkol sa modelo. Paano ito nangyayari? Sa paanong paraan nakikipag-ugnayan ang view at controller sa modelo? Pagkatapos ng lahat, ang mga klase ng view ay hindi maaaring direktang tumawag sa mga pamamaraan ng mga klase ng modelo upang magbasa/magsulat ng data. Kung hindi, hindi namin masasabi na ang modelo ay independyente. Ang modelo ay isang hanay ng mga malapit na nauugnay na klase na hindi dapat magkaroon ng access ang view o ang controller. Upang ikonekta ang modelo sa view at controller, kailangan nating ipatupad ang pattern ng disenyo ng facade. Ang facade ng modelo ay ang layer sa pagitan ng modelo at ng user interface, kung saan ang view ay tumatanggap ng maginhawang na-format na data, at ang Controller ay nagbabago ng data sa pamamagitan ng pagtawag sa mga kinakailangang pamamaraan sa harapan. Sa huli, ang lahat ay ganito:
MVC: Ano ang makukuha natin?
Ang pangunahing layunin ng paradigm ng MVC ay paghiwalayin ang pagpapatupad ng lohika ng negosyo (ang modelo) mula sa visualization nito (ang view). Ang paghihiwalay na ito ay nagdaragdag ng mga posibilidad para sa muling paggamit ng code. Ang mga benepisyo ng MVC ay higit na nakikita kapag kailangan nating ipakita ang parehong data sa iba't ibang mga format. Halimbawa, bilang isang talahanayan, graph, o tsart (gamit ang iba't ibang view). Kasabay nito, nang hindi naaapektuhan kung paano ipinapatupad ang mga view, maaari naming baguhin kung paano kami tumugon sa mga pagkilos ng user (mga pag-click sa button, pagpasok ng data). Kung susundin mo ang mga prinsipyo ng MVC, maaari mong pasimplehin ang pagbuo ng software, pataasin ang pagiging madaling mabasa ng code, at pagbutihin ang pagpapalawak at pagpapanatili. Sa huling artikulo sa seryeng "Introduction to Enterprise Development," titingnan natin ang isang pagpapatupad ng MVC na binuo gamit ang Spring MVC. Bahagi 8. Sumulat tayo ng isang maliit na application gamit ang Spring Boot
Sa artikulong ito, malalaman natin ang isang bagay na tinatawag na MVC. Pag-uusapan natin kung ano ang MVC, hipuin ang kasaysayan nito, tuklasin ang mga pangunahing ideya at konsepto na nakapaloob sa MVC, tingnan ang hakbang-hakbang kung paano hatiin ang isang application sa mga module ng Model, View, at Controller, magsulat ng isang maliit na web application gamit ang Spring Boot, at, gamit ang Spring MVC bilang isang halimbawa, tingnan kung paano ipinapadala 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 tagamasid at harapan. At maging pamilyar sa mga kahilingan at tugon ng HTTP, unawain ang mga pangunahing kaalaman ng HTML, at alamin kung ano ang mga anotasyon ng Java. Kumuha ng isang tasa ng kape at meryenda, at maging komportable. Magsimula tayo.
Mula sa lahat ng ito, maaari tayong gumuhit ng isang lohikal na konklusyon. Ang isang kumplikadong sistema ay kailangang hatiin sa mga module. Ilarawan natin nang maikli ang mga hakbang upang makamit ang paghihiwalay na ito.
At ganito tayo nakarating sa isang application na binubuo ng tatlong module na tinatawag na model, view at controller. Ibuod natin:
