diskarte sa MVC

Panimula sa arkitektura ng MVC

Ang pinakasikat na arkitektura ng application na alam ng bawat programmer ay ang MVC . Ang MVC ay nangangahulugang Model-View-Controller .

Ito ay hindi gaanong arkitektura ng mga application bilang ang arkitektura ng mga bahagi ng application, ngunit babalik tayo sa nuance na ito mamaya. Ano ang MVC?

Ang MVC ay isang pamamaraan para sa paghihiwalay ng data ng aplikasyon at pagkontrol ng lohika sa tatlong magkakahiwalay na bahagi— modelo, view, at controller —upang ang bawat bahagi ay maaaring mabago nang nakapag-iisa.

• Ang Model (Model) ay nagbibigay ng data at tumutugon sa mga command ng controller sa pamamagitan ng pagbabago ng estado nito.
• Responsable ang View sa pagpapakita ng data ng modelo sa user bilang tugon sa mga pagbabago sa modelo.
• Ang Controller (Controller) ay binibigyang-kahulugan ang mga aksyon ng user, na nagpapaalam sa modelo ng pangangailangan para sa mga pagbabago.

Ang modelong ito ay naimbento noong 1978 (!) Taon. Oo, ang mga problema sa wastong arkitektura ng software ay may kaugnayan 50 taon na ang nakakaraan. Narito kung paano inilalarawan ang modelong ito ng diagram sa orihinal:

Ang modelo ay nagbibigay ng data at mga pamamaraan para sa pagtatrabaho sa kanila: mga query sa database, pagsuri para sa kawastuhan. Ang modelo ay independiyente sa view (hindi alam kung paano mag-render ng data) at ang controller (walang mga punto sa pakikipag-ugnayan ng user), na nagbibigay ng access at pamamahala ng data.

Ang modelo ay binuo sa paraang tumugon sa mga kahilingan sa pamamagitan ng pagbabago ng estado nito, at ang abiso ng "mga tagamasid" ay maaaring i-built in. Ang modelo, dahil sa kalayaan mula sa visual na representasyon, ay maaaring magkaroon ng ilang magkakaibang representasyon para sa isang "modelo".

Ang view ay responsable para sa pagkuha ng kinakailangang data mula sa modelo at ipadala ito sa user. Hindi pinoproseso ng view ang input ng user.

Ang controller ay nagbibigay ng "komunikasyon" sa pagitan ng user at ng system. Kinokontrol at idinidirekta ang data mula sa user patungo sa system at vice versa. Gumagamit ng modelo at view para ipatupad ang gustong aksyon.

Mayroong isang tiyak na kahirapan sa katotohanan na ang modelong ito ay nagbago nang kaunti sa mga dekada. Iyon ay, ang pangalan ay nanatiling pareho, ngunit ang layunin ng mga bahagi ay nagsimulang magbago.

MVC architecture sa web

Ang ideya sa likod ng pattern ng disenyo ng MVC ay napaka-simple: kailangan naming malinaw na paghiwalayin ang responsibilidad para sa iba't ibang mga pag-uugali sa aming mga application:

Modelo— pagproseso ng data at lohika ng aplikasyon.

tingnan— pagbibigay ng data sa user sa anumang sinusuportahang format.

Controller- pagpoproseso ng mga kahilingan ng gumagamit at pagtawag sa naaangkop na mga mapagkukunan.

Ang application ay nahahati sa tatlong pangunahing bahagi, ang bawat isa ay may pananagutan para sa iba't ibang mga gawain. Tingnan natin ang mga bahagi ng isang client-server application gamit ang isang halimbawa.

Controller

Nag-click ang user sa iba't ibang elemento sa page sa browser, bilang resulta kung saan nagpapadala ang browser ng iba't ibang mga kahilingan sa HTTP: GET, POST, o iba pa. Maaaring isama ng controller ang browser at JS code na gumagana sa loob ng page.

Ang pangunahing pag-andar ng controller sa kasong ito ay upang tawagan ang mga pamamaraan sa mga kinakailangang bagay, pamahalaan ang pag-access sa mga mapagkukunan upang maisagawa ang mga gawain na tinukoy ng gumagamit. Kadalasan, tinatawag ng controller ang naaangkop na modelo para sa gawain at pinipili ang naaangkop na view.

Modelo

Ang modelo sa isang malawak na kahulugan ay ang data at mga panuntunan na ginagamit upang gumana sa data - magkasama silang bumubuo sa lohika ng negosyo ng application. Ang pagdidisenyo ng isang application ay palaging nagsisimula sa pagbuo ng mga modelo ng mga bagay na pinapatakbo nito.

Sabihin na nating mayroon tayong online na tindahan na nagbebenta ng mga libro, kung gayon ang isang tao ba ay isang gumagamit lamang ng aplikasyon o isang may-akda din ng isang libro? Ang mahahalagang tanong na ito ay dapat matugunan sa panahon ng disenyo ng modelo.

Karagdagan, mayroong mga hanay ng mga panuntunan: kung ano ang maaaring gawin, kung ano ang hindi maaaring gawin, kung aling mga set ng data ang katanggap-tanggap at alin ang hindi. Maaari bang umiral ang isang libro nang walang may-akda? At ang may-akda na walang mga libro? Maaari bang ang petsa ng kapanganakan ng gumagamit ay nasa taong 300 at iba pa.

Ang modelo ay nagbibigay sa controller ng view ng data na hiniling ng user (mensahe, pahina ng libro, mga larawan, atbp.). Magiging pareho ang modelo ng data kahit paano natin ito gustong ipakita sa user. Samakatuwid, pipili kami ng anumang available na view upang ipakita ang data.

Ang modelo ay naglalaman ng pinakamahalagang bahagi ng aming application logic , ang logic na lumulutas sa problemang kinakaharap namin (forum, shop, bangko, atbp.). Ang controller ay naglalaman ng halos organisasyonal na lohika para sa application mismo (tulad ng iyong Project Manager).

Tingnan

Nagbibigay ang View ng iba't ibang paraan upang kumatawan sa data na natanggap mula sa modelo. Maaari itong maging isang template na puno ng data. Maaaring may iba't ibang view at pipiliin ng controller kung alin ang pinakamainam para sa kasalukuyang sitwasyon.

Ang isang web application ay karaniwang binubuo ng isang hanay ng mga controller, modelo, at view. Ang controller ay maaari lamang sa backend, ngunit maaari ding magkaroon ng isang variant ng ilang mga controller, kapag ang logic nito ay kumalat din sa frontend. Ang isang magandang halimbawa ng diskarteng ito ay anumang mobile application.

Halimbawa ng MVC sa web

Sabihin nating kailangan mong bumuo ng isang online na tindahan na magbebenta ng mga libro. Maaaring gawin ng user ang mga sumusunod na aksyon: tingnan ang mga aklat, magparehistro, bumili, magdagdag ng mga item sa kasalukuyang order, markahan ang mga aklat na gusto niya at bilhin ang mga ito.

Ang iyong aplikasyon ay dapat magkaroon ng isang modelo na responsable para sa lahat ng lohika ng negosyo. Kailangan mo rin ng controller na magpoproseso ng lahat ng pagkilos ng user at gagawing method calls mula sa business logic. Gayunpaman, ang isang paraan ng controller ay maaaring tumawag sa maraming iba't ibang mga pamamaraan ng modelo.

Kailangan mo rin ng mga set ng view: isang listahan ng mga libro, impormasyon tungkol sa isang libro, isang shopping cart, isang listahan ng mga order. Ang bawat pahina ng isang web application ay talagang isang hiwalay na view na nagpapakita ng isang partikular na aspeto ng modelo sa user.

Tingnan natin kung ano ang mangyayari kung magbubukas ang isang user ng isang listahan ng mga bookstore na inirerekomendang aklat upang tingnan ang mga pamagat. Ang buong pagkakasunud-sunod ng mga aksyon ay maaaring ilarawan sa anyo ng 6 na hakbang:

Mga hakbang:

1. Nag-click ang user sa link na "inirerekomenda" at nagpapadala ang browser ng kahilingan sa, sabihin, /books/recommendations.
2. Sinusuri ng controller ang kahilingan : dapat naka-log in ang user. O dapat mayroon tayong mga koleksyon ng mga aklat para sa mga hindi naka-log in na user. Pagkatapos ay tatawagan ng controller ang modelo at hihilingin itong ibalik ang listahan ng mga aklat na inirerekomenda sa user na si N.
3. Ina-access ng modelo ang database, kinukuha ang impormasyon tungkol sa mga libro mula doon: mga aklat na kasalukuyang sikat, mga aklat na binili ng gumagamit, mga aklat na binili ng kanyang mga kaibigan, mga aklat mula sa kanyang listahan ng nais. Batay sa data na ito, bubuo ang modelo ng listahan ng 10 inirerekomendang aklat at ibinabalik ang mga ito sa controller.
4. Ang controller ay tumatanggap ng isang listahan ng mga inirerekomendang aklat at tinitingnan ito. Sa yugtong ito, ang controller ay gumagawa ng mga desisyon! Kung kakaunti ang mga aklat o ang listahan ay ganap na walang laman, humihiling ito ng listahan ng mga aklat para sa isang hindi naka-log na user. Kung may promosyon na nagaganap ngayon, maaaring magdagdag ang controller ng mga pampromosyong aklat sa listahan.
5. Tinutukoy ng controller kung aling page ang ipapakita sa user. Maaari itong maging isang pahina ng error, isang pahina na may listahan ng mga libro, isang pahina na binabati na ang gumagamit ay naging isang milyong bisita.
6. Ang server ay nagbibigay sa kliyente ng pahina ( view ) na pinili ng controller. Ito ay puno ng kinakailangang data (username, listahan ng mga libro) at pupunta sa kliyente.
7. Natanggap ng kliyente ang pahina at ipinapakita ito sa gumagamit.

Ano ang mga pakinabang ng pamamaraang ito?

Ang pinaka-halatang bentahe na makukuha natin sa paggamit ng konsepto ng MVC ay isang malinaw na paghihiwalay ng lohika ng presentasyon (interface ng gumagamit) at lohika ng aplikasyon (backend).

Ang pangalawang bentahe ay ang paghahati ng bahagi ng server sa dalawa: isang matalinong modelo ( executor ) at isang controller ( decision center ).

Sa nakaraang halimbawa, nagkaroon ng sandali kung kailan maaaring makatanggap ang controller ng isang walang laman na listahan ng mga inirerekomendang aklat mula sa modelo at magpasya kung ano ang gagawin dito. Sa teorya, ang lohika na ito ay maaaring direktang ilagay sa modelo.

Una, kapag humihiling ng mga inirerekomendang aklat, magpapasya ang modelo kung ano ang gagawin kung walang laman ang listahan. Pagkatapos ay kailangan kong idagdag ang code sa parehong lugar, kung ano ang gagawin kung may promosyon na nangyayari ngayon, pagkatapos ay higit pang iba't ibang mga pagpipilian.

Pagkatapos ay lumabas na gusto ng admin ng tindahan na makita kung ano ang magiging hitsura ng pahina ng gumagamit nang walang promosyon, o kabaliktaran, walang promosyon ngayon, ngunit gusto niyang makita kung paano ipapakita ang hinaharap na promosyon. At walang mga pamamaraan para dito. Samakatuwid, napagpasyahan na paghiwalayin ang sentro ng desisyon (controller) mula sa lohika ng negosyo (modelo).

Bilang karagdagan sa paghihiwalay ng mga view mula sa lohika ng aplikasyon, ang konsepto ng MVC ay lubos na binabawasan ang pagiging kumplikado ng malalaking aplikasyon. Ang code ay higit na nakabalangkas, na ginagawang mas madali ang pagpapanatili, pagsubok, at muling paggamit ng mga solusyon.

Ang pag-unawa sa konsepto ng MVC, ikaw, bilang isang developer, napagtanto kung saan mo kailangang magdagdag ng pag-uuri ng listahan ng mga aklat:

• Sa antas ng query sa database.
• Sa antas ng lohika ng negosyo (modelo).
• Sa antas ng lohika ng negosyo (controller).
• Sa view - sa gilid ng kliyente.

At ito ay hindi isang retorika na tanong. Sa ngayon, isipin kung saan at bakit kailangan mong idagdag ang code para sa pag-uuri ng listahan ng mga aklat.

Klasikong MVC na Modelo

Ang pakikipag-ugnayan sa pagitan ng mga bahagi ng MVC ay ipinapatupad sa ibang paraan sa mga web application at mga mobile application. Ito ay dahil ang web app ay panandalian, pinoproseso ang isang kahilingan ng user at lalabas, habang ang mobile app ay nagpoproseso ng maraming kahilingan nang hindi nagre-restart.

Ang mga web application ay karaniwang gumagamit ng "passive" na modelo, habang ang mga mobile application ay gumagamit ng "aktibo" na modelo. Ang aktibong modelo, hindi katulad ng passive, ay nagpapahintulot sa iyo na mag-subscribe at makatanggap ng mga abiso ng mga pagbabago dito. Hindi ito kinakailangan para sa mga web application.

Ganito ang hitsura ng interaksyon ng mga bahagi sa iba't ibang modelo:

Ang mga mobile application (aktibong modelo) ay aktibong gumagamit ng mga kaganapan at mekanismo ng subscription sa kaganapan. Sa diskarteng ito, nagsu-subscribe ang view ( view ) sa mga pagbabago sa modelo. Pagkatapos, kapag may nangyaring kaganapan (halimbawa, nag-click ang user sa isang button), ang controller ay tinatawag na . Binibigyan din nito ang modelo ng utos na baguhin ang data.

Kung nagbago ang ilang data, bubuo ang modelo ng kaganapan tungkol sa pagbabago ng data na ito. Ang lahat ng view na nag-subscribe sa kaganapang ito (kung saan mahalagang baguhin ang partikular na data na ito) ay nakakatanggap ng kaganapang ito at nag-a-update ng data sa kanilang interface.

Sa mga web application, medyo iba ang pagkakaayos ng mga bagay. Ang pangunahing teknikal na pagkakaiba ay hindi makakatanggap ang kliyente ng mga mensahe sa gilid ng server sa inisyatiba ng server .

Samakatuwid, ang isang controller sa isang web application ay karaniwang hindi nagpapadala ng anumang mga mensahe sa view, ngunit nagbibigay sa kliyente ng isang bagong pahina, na teknikal na isang bagong view o kahit isang bagong application ng kliyente (kung ang isang pahina ay walang alam tungkol sa isa pa) .

Sa kasalukuyang panahon, ang problemang ito ay bahagyang nalutas gamit ang mga sumusunod na pamamaraan:

• Regular na pagboto sa server para sa mga pagbabago sa mahalagang data (minsan sa isang minuto o higit pa).
• Pinapayagan ng WebSockets ang isang kliyente na mag-subscribe sa mga mensahe ng server.
• Web push notifications mula sa server side.
• Ang HTTP/2 protocol ay nagpapahintulot sa server na simulan ang pagpapadala ng mga mensahe sa kliyente.