Etuosan MV * -kehyksen merkitys

Meaning Front End Mv Framework



Usein kysytään, mikä merkitys on MV *: n harjoittamiseen etupäässä? Jotkut ihmiset ovat esittäneet kysymyksen: Mikä on ero MV * -kehyksen, jota edustavat AngularJS, Knockout ja BackBone, ja jQueryn kaltaisen kehyksen välillä? Olen käyttänyt jQueryä hyvin, onko tarpeen ottaa tämä kehys käyttöön?

Ennen kuin vastaamme näihin kysymyksiin, meidän on ensin selvitettävä historiaa. Milloin käyttöliittymällä oli kehys?



Varhaiset käyttöliittymät ovat suhteellisen yksinkertaisia, pohjimmiltaan sivu on työyksikkö, sisältö on pääasiassa selaustyyppiä ja joskus on yksinkertaisia ​​lomaketoimintoja. Tänä aikana kussakin käyttöliittymässä on vain muutama JavaScript-logiikka, eikä kehystä tarvita paljon. AJAX: n tulon ja Web 2.0: n myötä ihmiset voivat tehdä monimutkaisempia asioita sivulla, ja sitten käyttöliittymäkehys, jota edustaa jQuery, todella ilmestyy käyttöliittymän tavallisille DOM-toiminnoille, etäkyselyille, tiedoille. Käsittely on koteloitu, ja on myös alakohta, joka keskittyy tietojen käsittelyyn. Tarkkaan ottaen nämä eivät ole kehyksiä, vaan kirjastot.



Kirjastojen ja kehysten välillä on joitain eroja: kirjastot ovat työkalu, jonka tarjoan, sinun ei tarvitse, vaikka käyttäisit sitä, se ei vaikuta omaan koodirakenteeseen. Kehys on verkkotunnukselle, joka tarjoaa ratkaisun. Jos käytät minua, sinun on tehtävä asioita omalla tavallani. Tämän määritelmän mukaan sekä jQueryä että Alaviivaa voidaan pitää vain kirjastoina, ExtJS- ja dojo-laskentakehyksinä.

Miksi MV * -kehys nousee? Sen esiintyminen yhdessä joidenkin verkkotuotteiden kehityksen kanssa sovellussuunnassa kohtasi saman ongelman C / S-kentässä: käyttöliittymän toimintojen parantamisen, koodin laajentamisen vuoksi sen on tehtävä etupään arkkitehtuuri-juttu.

Monet taustakehitystä tekevät ihmiset ovat hyvin halveksivia käyttöliittymän arkkitehtuurista. He ajattelevat, että käyttöliittymä on vain ohut kerros asioista. Mitä arkkitehtuuri tekee? Mitä paitsi arkkitehtuurin, myös MVC: n harjoittamiseen? Java Strutsin MVC: ssä koko käyttöliittymää voidaan pitää vain näkymänä. Sinun on myös jaettava malli, ohjain ja muut tässä näkymässä? Suurin osa heistä suhtautuu tähän hyvin halveksivasti, mutta web-käyttöliittymän monimutkaisuuden lisääntyessä monet paikat eivät enää ole olennaisesti erilaisia ​​asiakkaasta.



jQueryn ajattelutapa on: keskittyminen DOM-toimintoihin

Ajattelutapa MV * -kehyksestä on: mallikeskeinen, DOM-toiminnot ovat vain liitteenä

Joten palatakseni tähän kysymykseen, jQuery vastaa yrityksesi tarpeisiin, mitä muuta tarvitset MV * -kehyksen käyttöönottoon?

Tämä riippuu tuotetyypistä. Jos kyseessä on sivutyyppinen tuote, useimmat niistä eivät tarvitse sitä. Koska sivulla oleva JavaScript-koodi käsittelee vuorovaikutusta paljon enemmän kuin käsittelymalli, mutta jos se on sovellusohjelmistotuote, sitä tarvitaan myös liian paljon.

Yritykset, jotka ovat pitkään työskennelleet teollisuuden ohjelmistojen parissa, yleensä saostavat joitain liiketoiminnan komponentteja, lähinnä tietomalleissa, liiketoimintasäännöissä ja liiketoimintaprosesseissa. Nämä komponentit ovat periaatteessa takapäässä, ja vastaavia organisaatioita on vain vähän etupäässä. Aikaisemmassa kokemuksessa he ovat tehneet MVC: n, mutta yrittäneet myös tehdä joitain liitäntäkomponentteja, mutta käytäntö on vanhentunut, kuten JSF: n tai GWT: n käyttö.

Mikä on JSF: n ongelma? Ongelma ei ole siinä, että käyttöliittymä on sekoitettu logiikkaan. Niin kutsuttu vertikaalinen segmentointikomponentti, puhdas Polymer-käyttöliittymän kehys, on myös niin jaettu. Ongelmana on, että komponenttia ei luoda ja hahmonneta samassa paikassa. Siksi loogisen koodin sijainti on hyvin kiusallista. Jos käyttöliittymä on yksinkertainen, se on hyvin monimutkainen. Se on tietysti käyttöliittymän logiikkakoodi, mutta se on luotava taustapuolen kautta.

GWT on suhteellisen parempi tällä tavalla. Ongelmana on, että käyttöliittymän säätömahdollisuus on liian pieni ja suhteellisen joustamaton.

Tällaisella komponenttitekniikalla, joka perustuu jonkinlaiseen palvelintekniikkaan, on joitain rajoituksia. Esimerkiksi se rajoittaa etupäätä suurelta osin. Alkuvaiheissa tämä menetelmä voi olla hyvä, mutta nyt ajan kehittyessä käyttäjät ovat. Etupään käyttäjäkokemus on tulossa yhä korkeammalle, ja meidän on laitettava paljon energiaa takaisin käyttöliittymään. Toinen ongelma JSF: ssä ja muissa ratkaisuissa on, että se on sidottu jonkinlaiseen palvelinympäristöön, ja on vaikea vaihtaa toisenlaiseen taustajärjestelmään. Jos haluat käyttää Hybird-kehitystä, on melkein mahdotonta käyttää jotakin käyttöliittymän logiikkaa.

Joten katsotaanpa puhdas käyttöliittymäkehys ja katsotaan, miten ne ratkaistaan. Otetaan esimerkkinä Google. Se käynnisti kaksi kehystä, Polymer ja Angular, ja se on rinnakkaisen kehityksen vaiheessa. Näiden kahden käsitteen välillä on edelleen suuri ero, mikä on aiheuttanut sekaannusta monille ihmisille.

Tapa, jolla komponentti on jaettu komponentteihin, on jonkin verran samanlainen kuin JSF. Sillä on paljon tekemistä HTML5-standardin Shadow DOM: n ja Elementin kanssa. Tämä tapa jakaa komponentit on hyvin intuitiivinen. Jokainen komponentti on päästä päähän, sisältää suoraan käyttöliittymän ja logiikan. Sitä voidaan käyttää asettamalla se rajapintaan. Yrityskehittäjät hyväksyvät tämän menetelmän helposti, mutta sisällä olevaa ajoitusta on vaikeampaa käsitellä.

Esimerkiksi on kaksi komponenttia, joista kukin sisältää avattavan ruudun, datalla on linkityssuhde, koska ne ovat kahdessa eri komponentissa, linkityksen käsittelykoodia on vaikea kirjoittaa komponentin ominaisuudet huomioon ottaen, yrittää piilottaa oman sisäisen toteutuksensa, jotta saat elementin komponentin sisältä kiertämään kerroksen, eikä komponentti voi luottaa muihin ulkoisiin asioihin, joten lopulta vain tapahtuman kautta saavutettavaksi tämä linkityskoodi tulisi olla sijoitettu sinne, missä se pitäisi sijoittaa, myös iso ongelma. Esimerkkimme on juuri niin yksinkertainen. On välttämätöntä kiertää niin iso ympyrä ajoituksen takaamiseksi. Jos kohtaus on monimutkainen, sitä on vaikea hallita.

Jos samaa komponenttia käytetään uudelleen useita kertoja käyttöliittymässä, tietojen yhtenäisyyttä on vaikea taata. Kuvittele, että yhdessä liitännässä on kaksi samanlaista pudotusvalintaruutua, jotka ovat eri komponenteissa, ja molempien tietojen on oltava erikseen ladattavia, tämä prosessi on tuhlaavaa. Lisäksi, jos tätä avattavaa ruutua vastaavat tiedot päivitetään, kutakin esiintymää on vaikea päivittää. Tämä prosessi on erittäin hankala.

Kulmakehys käsittelee ongelmaa eri tavalla. Se on vaakatasossa kerrostettu. Kaikki nämä tiedonsiirtologiikat on erotettu täysin käyttöliittymästä, joten tämän logiikkakoodin kirjoittaminen on erittäin helppoa, niin että yllä mainitut komponentit lopussa ovat täysin huonontuneet ja niistä tulee vain käyttöliittymä.

Katso kahta juuri kohtaamaasi ongelmaa. Ensinnäkin mallikoodi jaetaan liiketoiminta-alueen mukaan. Hankitut tiedot sijoitetaan kahteen eri ryhmään ja liitetään sitten käyttöliittymään kaksisuuntaisen sitomisen avulla. Jos käyttöliittymässä on valittu pudotusvalikko. Kun kohde muuttuu, sinun on vain seurattava tätä arvokohtaa ja päivitettävä sitten toisen avattavan ruudun arvoluettelo, sinun ei tarvitse taivuttaa ympärilläsi. Vaikka nämä kaksi ovat eri malleissa, voit käyttää tapahtumaväylän kaltaista mekanismia viestinnän loppuun saattamiseksi samalla tavalla kuin takapää.

Toinen on yksinkertaisempi. Uudelleen käytetty komponentti on itse asiassa vain käyttöliittymä. Toisin sanoen vain käyttöliittymä on moni-ilmentymä. Mallissa on itse asiassa vain yksi kopio, esimerkiksi alueen puurakenne, vaikka yhdessä käyttöliittymässä on ylläpitoa ja käyttöä. Molemmat toiminnot voivat jakaa saman mallin. Kun tiedot päivitetään huoltopuolella, ne syötetään takaisin malliin reaaliajassa, ja sitten kaksisuuntaista sidontaa käytetään mallin synkronointiin käyttöliittymän käyttäjän kanssa. Koko prosessi on selkeä. hallinta.

Yhteistyön näkökulmasta monien etupään kehitystiimin jäsenten vastuut eivät ole kovin selkeitä. Etupään MV * -kehyksen avulla tilanne paranee huomattavasti. MV * -kehyksen idea on kerrosta käyttöliittymä vastuunsa mukaan. Jokainen kerros on suhteellisen riippumaton, sillä on oma arvo ja oma kehitystila.

Miksi suurin osa Internet-käyttöliittymäkehitystä tekevistä opiskelijoista kokee MV * -kehyksen tärkeyden, koska tässä yhteistyöjärjestelmässä malli ei ole tarpeeksi monimutkainen. Perinteisessä ohjelmistokentässä malliosa on eniten koodattu, ja näkymä on suhteellinen. Vähemmän, ja Internet-maailmassa perus on päinvastainen, joten malli on pieni lisäys, jos päätoiminto on View and Controller, niin tietysti jQueryn kehys on hyödyllisempi.

Siksi opiskelijat, joilla on Internet-tuotteita, puhuvat usein käyttöliittymän MVC: stä, mutta kun ne ovat esimerkkejä, he ovat kaukaa haettuja. Monissa tapauksissa heidän mainitsemansa malli ei todellakaan ole oikea malli, vaan View-toiminnon prosessissa. Jotkut apumallit, todellinen malli on edessä ja takana.

Loppujen lopuksi käyttöliittymän MV * -kehys tuo mukanaan joukon työnkulun muutoksia. Taustajärjestelmän insinöörit voivat myös kirjoittaa etupään mallikoodin ja avata sen perusteellisesti taustapuolella. Vuorovaikutusinsinööri hoitaa käyttöliittymän ja mallin välisen vuorovaikutuksen. Käyttöliittymän henkilökunta voi keskittyä HTML-lähdekoodiin ja käsitellä sitä sekä toimittaa niitä interaktiivisille insinööreille käyttöliittymämallien muodossa. Tämä koko yhteistyömekanismi voi parantaa merkittävästi B / S-arkkitehtuurijärjestelmän kehitystehokkuutta. Jos on olemassa oheislaitteiden hallinta- ja ohjausalusta, tuotannon tehokkuus siirtyy todella teollistumisen vaiheeseen.

Mikä on etupään kehittäjien tie tässä vaiheessa? Mielestäni on olemassa kahdenlaisia. Vertaa vaatetusteollisuutta, jos haluat tavallista, käytä teollisia keinoja massatuotantoon, käytä MV * -kehystä, tee hyvää arkkitehtuuria ja komponenttien uudelleenkäyttöä, tee se nopeasti, yksityiskohdat eivät ole kovin erityisiä. Jos haluat olla parempi ja erottuva, tarvitset suunnittelijan, käsin rakennettu, erittäin hienostunut, huippuluokan ilmapiiri. Siksi tämä edustaa etupään kehityksen kahta kehityssuuntaa.

Painettu uudelleen: https://www.cnblogs.com/Blog-Yang/p/3385383.html