Մեկ էջանոց սպա վեբ պորտալի հայեցակարգը և նպատակը: Մեկ էջի հավելվածներ. Մեկ էջի հավելվածի իրականացում

Այս հոդվածը կկենտրոնանա մեկ էջի հավելվածի վրա (SPA): Կդիտարկվեն մեկ էջանոց կայքի (SPA) սկզբունքներով կառուցված վեբ հավելվածի դրական և բացասական կողմերը:

Ինչ է SPA-ն

Մեկ էջի հավելված - հապավումը որպես SPA, ռուսերեն թարգմանված նշանակում է «Մեկ էջի դիմում»: Այլ կերպ ասած, SPA-ն վեբ-հավելված է, որը տեղակայված է մեկ վեբ էջում, որը ներբեռնում է բոլոր անհրաժեշտ ծածկագիրը հենց էջի հետ միասին՝ այն գործելու համար: Այս տեսակի հավելվածը հայտնվեց համեմատաբար վերջերս՝ HTML5 դարաշրջանի սկզբով, և SPA-ն HTML5 հավելվածների տիպիկ ներկայացուցիչն է։

Ինչպես գիտենք, HTML5-ը ոչ այլ ինչ է, քան HTML + CSS3 + JavaScript + [մի քանի նոր պիտակներ]: Այսպիսով, SPA-ները JavaScript-ով գրված հավելվածներ են։ Եվ, հետևաբար, մի փոքր վերափոխելով նախորդ սահմանումը, մենք ստանում ենք.

«SPA-ն վեբ հավելված է, որը տեղակայված է մեկ էջի վրա, որը բեռնում է բոլոր javascript ֆայլերը (մոդուլներ, վիդջեթներ, հսկիչներ և այլն) աշխատելու համար, ինչպես նաև css ֆայլերբուն էջի բեռնման հետ մեկտեղ»։

Եթե հավելվածը բավականին բարդ է և պարունակում է հարուստ ֆունկցիոնալություն, օրինակ՝ էլեկտրոնային փաստաթղթերի կառավարման համակարգ, ապա սկրիպտներով ֆայլերի թիվը կարող է հասնել մի քանի հարյուրի կամ նույնիսկ հազարների: Եվ «…բոլոր սկրիպտները բեռնելը…» ոչ մի կերպ չի նշանակում, որ երբ կայքը բեռնվի, սկրիպտներով բոլոր հարյուրավոր և հազարավոր ֆայլերը միանգամից կբեռնվեն: SPA-ում մեծ թվով սկրիպտներ բեռնելու խնդիրը լուծելու համար կոչվում է API, որը կոչվում է AMD: AMD-ն իրականացնում է սկրիպտներ ըստ պահանջի բեռնելու հնարավորություն: Այսինքն, եթե մեկ էջանոց պորտալի «հիմնական էջի» համար պահանջվում էր 3 սկրիպտ, դրանք կբեռնվեն ծրագրի մեկնարկից անմիջապես առաջ։ Եվ եթե օգտատերը սեղմել է մեկ էջանոց պորտալի մեկ այլ էջ, օրինակ՝ «Մոտ», ապա AMD սկզբունքը կբեռնի մոդուլը (սկրիպտ + նշում) հենց այս էջ գնալուց առաջ։

Մի փոքր ճմրթված է ստացվում՝ «Մի էջ.. մեկ այլ էջ, երրորդ էջ... մեկ էջանոց պորտալ»։ Եկեք կետադրենք բոլոր «Յո»-ները: Կայքի այն էջը, որը պարունակում է բոլոր CSS-ի բոլոր հղումները և SPA-ի աշխատանքի համար անհրաժեշտ սկրիպտների հղումները, մենք կանվանենք «Վեբ էջ»: Նման էջից ֆայլը սովորաբար կոչվում է «index.html» (ASP.NET MVC-ում այն կարող է լինել index.cshtml կամ index.vbhtml կամ նույնիսկ index.aspx) և այն էջերը, որոնք օգտվողը փոխում է մեկ էջի ներսում: պորտալը կոչվելու է «մոդուլներ»:

Եկեք նայենք այս մոտեցման դրական և բացասական կողմերին: Ինչու է այս ամենը անհրաժեշտ և ինչու է SPA-ն այդքան տարածված:

SPA: Կողմ

Առաջին առավելությունն այն է, որ SPA հավելվածները հիանալի են աշխատում ինչպես ստացիոնար, այնպես էլ շարժական սարքերի վրա: «Խոշոր» համակարգիչներ, պլանշետներ, սմարթֆոններ և, ի վերջո, պարզ հեռախոսներ(ոմանք) կարող են անխափան աշխատել SPA-ի սկզբունքով կառուցված կայքերի հետ: Այսպիսով, առաջին «գումարածը»՝ աշխատել մեծ թվով սարքերի վրա, ինչը նշանակում է, որ մեկ հավելված ստեղծելով, դուք ստանում եք օգտատերերի շատ ավելի մեծ լսարան, քան ստանդարտ մոտեցումն օգտագործելիս։

Հետագա երկրորդ «գումարածը» հարուստ ինտերֆեյս է, այսպես կոչված Օգտատիրոջ փորձը։ Քանի որ կա միայն մեկ վեբ էջ, հարուստ, հարուստ ինտերֆեյսի ստեղծումը շատ ավելի հեշտ է: Ավելի հեշտ է պահել նիստի տեղեկատվությունը, կառավարել դիտման վիճակները և կառավարել անիմացիաները (որոշ դեպքերում):

Երրորդ «գումարածը»՝ SPA-ն զգալիորեն (երբեմն) նվազեցնում է այսպես կոչված «շրջանակով քայլելը», այսինքն՝ նույն բովանդակությունը նորից ու նորից ներբեռնելը: Եթե ձեր պորտալը (կայքը) օգտագործում է ձևանմուշ, ապա ցանկացած էջի հիմնական բովանդակության հետ մեկտեղ կայքի այցելուն պետք է ներբեռնի կաղապարի նշումը: Այո, WWW-ի զարգացման այս փուլում տվյալների քեշավորումը հասել է ամենաբարձր արդյունքների, բայց եթե քեշավորման բան չկա, ապա դրա վրա և՛ ժամանակը, և՛ ռեսուրսները չեն վատնում։

SPA: Դեմ

Եթե դուք ծրագրավորում եք C#-ով, ապա SPA-ի միակ թերությունն անհրաժեշտությունն է սովորել javascript. Ամեն դեպքում, մյուսները գլոբալ խնդիրներԻնձ չհաջողվեց պարզել։

SPA բաղադրիչներ

Ցանկացած շրջանակի սկզբունքները (դրանց մասին կխոսենք ավելի ուշ), որն իրականացնում է SPA պարադիգմը, պետք է հետևեն հետևյալ հասկացություններին և սահմանումներին.

SPA-ն աջակցում է հաճախորդների նավիգացիան: Օգտատիրոջ բոլոր «քայլերը» մոդուլ-էջերի միջով միանշանակ գրանցվում են նավիգացիայի պատմության մեջ, իսկ նավարկությունը «խորը» է, այսինքն՝ եթե օգտատերը պատճենում և բացում է ներքին մոդուլ-էջի հղումը մեկ այլ բրաուզերում կամ պատուհանում: , նրան կտեղափոխեն համապատասխան էջ։
SPA-ն գտնվում է մեկ վեբ էջում, ինչը նշանակում է, որ կայքի (պորտալի) աշխատանքի համար անհրաժեշտ բոլոր սցենարներն ու ոճերը պետք է սահմանվեն նախագծում մեկ տեղում՝ մեկ վեբ էջում:
SPA-ն մշտապես պահպանում է հաճախորդի (հաճախորդի սկրիպտի) գործողության վիճակը (կարևոր փոփոխականները) բրաուզերի քեշում կամ վեբ պահեստում:
SPA-ն բեռնում է բոլոր սկրիպտները, որոնք անհրաժեշտ են հավելվածը սկսելու համար, երբ վեբ էջը սկզբնավորվում է:
SPA-ն աստիճանաբար բեռնում է մոդուլները ըստ պահանջի:

SPA կաղապարներ

Ինչպես կռահեցիք, SPA-ն վերացական հասկացություն է: Սա կիրառական ճարտարապետության սկզբունքն է: Եկեք խոսենք այն մասին, թե որտեղից սկսել SPA-ի սկզբունքներով կայքը մշակելիս:

Գոյություն ունեն մեծ թվով հիմնական գրադարաններ (framework - անգլերեն բառից frame - «հիմք, կառուցվածք, շրջանակ»), որոնք իրականացնում են Single Page Application սկզբունքը: Ինչ են ապահովում այս շրջանակները.

ապահովել ԲՀՊՏ-ի զարգացման հիմնական սկզբունքները՝ նվազագույնի հասցնելով աշխատուժի ծախսերը համընդհանուր խնդիրների լուծման համար (տե՛ս «SPA-ի բաղադրիչները» բաժինը.
շրջանակները ստեղծվում են ծրագրավորողների համայնքի կողմից, ինչը նշանակում է, որ նրանք օգտագործում են բազմաթիվ ծրագրավորողների կայքեր ստեղծելու փորձը.
Frameworks-ը մեկնարկային կետն է Single Page Application-ի վրա հիմնված կառուցվածք ստեղծելու համար:

Քանի որ ես երկար տարիներ աշխատել եմ NET հարթակի վրա, ես կդիտարկեմ ASP.NET-ի վրա հիմնված Single Page Application կաղապարներ: Եկեք նայենք հետևյալ համեմատական աղյուսակին.

SPA կաղապարի առանձնահատկությունների համեմատություն

Աղյուսակը ցույց է տալիս որպես հիմք մեկ էջի հավելված ստեղծելու ամենատարածված ձևանմուշները: Խնդրում ենք նկատի ունենալ, որ կապույտ ֆոնն ընդգծում է լիարժեք շրջանակ կառուցելու հիմնական բլոկները, ինչպիսիք են DurandalJS-ը և HotTowel-ը, որոնք ընդգծված են կանաչով:

Ամպի վրա հիմնված վեբ հավելվածները դառնում են ժողովրդականություն: Շատ ՏՏ ընկերություններ տեսնում են այս միտումը և ավելին ծրագրային արտադրանքհիման վրա մշակված հեռավոր մուտք. Կան սեղանադիր ծրագրերի բազմաթիվ անալոգներ, որոնք առաջարկում են առցանց տարբերակըչնչին ամսավճարով:

Նրանք տալիս են ավելի շատ ճկունություն և շարժունակություն: Օրինակ, դուք կարող եք հեշտությամբ մուտքագրել տվյալները ամպային CRM կամ ERP համակարգեր ձեր միջոցով Բջջային հեռախոսև դա կարող է տեղի ունենալ ձեզ համար հարմար վայրում: Ինչպես տեսնում եք Statista գրաֆիկից, ամպային լուծումների շուկան աճում է և մինչև 2026 թվականը պետք է հասնի գրեթե 522 միլիարդ դոլարի:

Ապահովել կայուն աշխատանքբարդ վեբ հավելվածներ, ցանկալի է օգտագործել տեխնոլոգիաներ, որոնք կտան լավագույն կատարումըև արագություն։ Վեբ հավելվածներ մշակելու երկու եղանակ կա՝ Single Page Applications (SPA) և Multi-Page Applications (MPA): Եկեք նայենք դրանց միջև եղած տարբերությանը և թե ինչ առավելություններ ունի վեբ հավելվածի յուրաքանչյուր տեսակ:

Մեկ էջանոց հավելվածները թույլ են տալիս մոդելավորել աշխատասեղանի հավելվածների աշխատանքը: Ճարտարապետությունը նախագծված է այնպես, որ անցում կատարելիս նոր էջ, բովանդակության միայն մի մասն է թարմացվում։ Այսպիսով, նույն տարրերը նորից ներբեռնելու կարիք չկա: Սա շատ հարմար է մշակողների և օգտագործողների համար: SPA-ն մշակվել է՝ օգտագործելով ամենահայտնի ծրագրավորման լեզուներից մեկը. javascript. jQuery գրադարանի միջոցով կարելի է փոքրիկ վեբ հավելված պատրաստել:

Բայց, արժե անմիջապես նշել, որ jQuery-ն շատ վատ է հարմար խոշոր նախագծեր մշակելու համար: Մեր ընկերությունը՝ Merehead-ը, խորհուրդ է տալիս ավելի հզոր տեխնոլոգիաներ օգտագործել SPA-ի զարգացման համար։ Այս նպատակների համար React.js-ը, Angular.js-ը, Vue.js-ը և այլ շրջանակներ/գրադարաններ լավ են համապատասխանում: Նրանց ճարտարապետությունը թույլ է տալիս զարգացնել ճկուն վեբ հավելվածներ: Ավելին, շրջանակների հիման վրա դուք կարող եք ստեղծել բջջային հավելվածներ՝ կրկնակի օգտագործման դեպքում, երբ: Նման հնարավորություններ են տալիս Rreact Native-ը և Ionic-ը: Մեկ էջի հավելվածի հիմնական առավելությունները.

Բարձր արագություն. Քանի որ SPA-ն չի թարմացնում ամբողջ էջը, այլ միայն անհրաժեշտ մասը, դա զգալիորեն մեծացնում է աշխատանքի արագությունը։
Զարգացման բարձր արագություն: Պատրաստի գրադարաններիսկ շրջանակները տալիս են հզոր գործիքներվեբ հավելվածների մշակման համար: Back-end և front-end ծրագրավորողները կարող են զուգահեռ աշխատել նախագծի վրա: Հստակ տարանջատման շնորհիվ նրանք միմյանց չեն խանգարի։
Բջջային հավելվածներ. SPA-ն հեշտացնում է բջջային հավելվածի մշակումը, որը հիմնված է պատրաստի կոդի վրա։

Իր բոլոր արժանիքներով, Single Page Application-ն ունի որոշ թերություններ, որոնք հետ են պահում նրա ժողովրդականության աճը.

Վատ SEO օպտիմիզացում. SPA-ն հիմնված է javascript-ի վրա և բեռնում է տեղեկատվությունը հաճախորդի կողմից խնդրանքով: Որոնման համակարգերդժվար է ընդօրինակել այս պահվածքը: Հետևաբար, էջերի մեծ մասը պարզապես հասանելի չէ որոնման բոտերի կողմից սուզվելու համար:
Ոչ ակտիվ javascript: Որոշ օգտվողներ անջատում են javascript-ը իրենց բրաուզերներում, և առանց դրա ձեր հավելվածը չի աշխատի:
Ցածր անվտանգություն.

JavaScript-ն ունի ցածր մակարդականվտանգություն, բայց եթե դուք օգտագործում եք ժամանակակից շրջանակներ, դրանք կարող են անվտանգ դարձնել ձեր վեբ հավելվածը: Բայց հարկ է նշել, որ օգտագործելով jQueryկարող է զգալիորեն նվազեցնել ձեր նախագծի անվտանգությունը:

Մեկ էջանոց վեբ հավելվածները հարմար են փոքր քանակությամբ տվյալների հետ դինամիկ հարթակներ մշակելու համար: Բացի այդ, եթե ապագայում ձեզ անհրաժեշտ է բջջային հավելված ստեղծել, SPA-ն հիանալի է որպես հիմք: Հիմնական թերությունը, որը հետ է պահում SPA-ի ժողովրդականության արագ աճը, SEO-ի վատ օպտիմիզացումն է: Այն նախագծերը, որտեղ SEO-ն առաջնահերթություն է, պետք է օգտագործեն MPA:

Բազմաէջ հավելված (MPA)

Բազմէջանոց հավելվածներն ավելի դասական ճարտարապետություն ունեն: Յուրաքանչյուր էջ հարցում է ուղարկում սերվերին և ամբողջությամբ թարմացնում է բոլոր տվյալները: Նույնիսկ եթե այս տվյալները փոքր են: Այսպիսով, կատարումը վատնում է նույն տարրերը ցուցադրելու համար: Համապատասխանաբար, սա ազդում է արագության և կատարողականի վրա: Շատ մշակողներ օգտագործում են JavaScript/jQuery արագությունը բարելավելու և բեռը նվազեցնելու համար: Լավ օրինակ, ապրանքների թարմացում՝ առանց էջը վերաբեռնելու, առցանց խանութում զտիչներ օգտագործելիս։ Դա շատ ավելի հարմար է և ամենակարևորն ավելի արագ։ Multi Page Application-ի (MPA) հիմնական առավելությունները.

Հեշտ SEO օպտիմիզացում: MPA ճարտարապետությունը բավականին հեշտացնում է յուրաքանչյուր էջի օպտիմալացումը որոնման համակարգերի համար:
Հեշտ զարգացում: Որպես կանոն, բազմաէջանոց հավելված մշակելու համար պահանջվում է ավելի փոքր տեխնոլոգիական փաթեթ։
Շատ լուծումներ.

MPA-ի միջոցով դուք կարող եք գտնել համապատասխան տուփով լուծում: Օրինակ, օգտագործեք Magento-ն, OpenCart-ը էլեկտրոնային առևտրի վեբ հավելվածներ մշակելու համար կամ Dolphin-ը, Elgg-ը՝ սոցիալական ցանցերը զարգացնելու համար: MPA-ի թերությունները.

Զարգացման համար բջջային հավելվածներդա շատ ավելի շատ ժամանակ կպահանջի: Շատ դեպքերում, դուք պետք է զրոյից գրել հետնամասը:
Դժվար է առանձնացնել առջևի վերջը և հետին մասը: Որպես կանոն, նրանք շատ սերտ են փոխազդում միմյանց հետ։ Front-end և back-end ծրագրավորողների աշխատանքն ավելի է բարդանում:

MPA-ի հիմնական առավելությունը SEO-ի լավ օպտիմիզացումն է և տուփային լուծումների հսկայական քանակությունը:

Այսօր ես կցանկանայի նկարագրել իմ տեսակետը զարգացման վերաբերյալ վեբ հավելվածներ(կամ մեկ էջի դիմում) Վեբ հավելվածը այն կայքն է, որի աշխատանքը հնարավորինս ամբողջությամբ փոխանցվում է հաճախորդի կողմին: Նման կայքը սերվերի հետ «շփվում» է միայն մաքուր տվյալներով՝ առանց html կոնտենտ ներբեռնելու։ Բոլոր կոճակները, ձևաթղթերը և այլն մշակվում են javascriptՕ, բոլոր ցուցակները, աղյուսակները, բլոկները և էջի այլ տարրերը փոխվում են Javascript-ի միջոցով: Այսինքն, սերվերը ուղարկում է միայն տվյալներ, սովորաբար ներս json ձևաչափովև հաճախորդի կողմը ինքնուրույն գեներացնում է կայքի էջը, բոլոր ձևանմուշները, ցուցակները, հղումները, աղյուսակները և այլ թարմացված տարրեր։

Մեկ էջի կիրառման հիմնական կանոնները

Վեբ հավելվածի բոլոր սուբյեկտները հիմնված են մոդելների և օբյեկտների վրա (էջի DOM տարրերի հետ աշխատանքը պարփակված է օբյեկտների ներսում):
HTML ձևանմուշները պահվում են սկրիպտներում (որքան հնարավոր է):
Էջի ցանկացած փոփոխություն:
Ցանկացած url-ի ուղղակի բեռնումը պետք է ցուցադրի համապատասխան տվյալների էջը:
Պատմություն back (բրաուզերի հետ կոճակը) պետք է ճիշտ վարվի և էջը վերադարձնի իր նախկին վիճակին:
Տվյալների մոդելների քեշավորում հաճախորդի կողմից:

Վերոնշյալ կետերը, իմ տեսանկյունից, հիմնականներն են։ Իհարկե, աշխատանքը օպտիմալացնելու, կամ համակարգը բարդացնելուց խուսափելու համար ինչ-որ բան պետք է զոհաբերել։

Վեբ հավելվածի հետ աշխատանքի հաջորդականությունը

Ինդեքսային էջը բեռնված է (կաղապարն ամբողջությամբ ցուցադրվում է և լրացվում է տվյալների հետ):
1. Բոլոր անհրաժեշտ օբյեկտները նախաստորագրված են և բոլոր իրադարձությունների ունկնդիրները սահմանված են:
Օգտագործողը սեղմում է հղման/կոճակի/ցանկացած ինտերակտիվ տարրի վրա:
Հավելվածը ընդհատում է սեղմման իրադարձությունը:
Եթե օբյեկտի վրա սեղմելը նշանակում է փոխել վեբ հավելվածի վիճակը ->
Մենք ձևավորում ենք նոր URI էջի նոր վիճակի համար:
Փոխեք ընթացիկ uri-ը javascript (փոխել uri առանց վերաբեռնման էջը).
Միջոցառումը գաղտնալսվում է URI փոփոխություններ.
Մենք վերլուծում ենք մեր նոր հասցեն, ստանում ենք բոլոր բանալին-արժեքները:
Մենք ստուգում ենք, թե ինչ է փոխվել ստեղների մեջ:
Մենք հարցում ենք ուղարկում սերվերին՝ նոր տվյալներ ստանալու համար:
Մենք ընդունում ենք պատասխանը և կանչում ենք հետ կանչի գործառույթը տվյալների հաջող բեռնման համար:
Էջի անհրաժեշտ հատվածների վերագծում:

Այս հաջորդականությամբ հարց է առաջանում 5-10 կետերի հաշվին (և տվյալների խնդրանք), ինչո՞ւ հասցեն փոխելիս անմիջապես տվյալներ չպահանջել։ Պատասխանը պարզ է. մենք ստեղծում ենք մեկ մուտքի կետ՝ uri-ի փոփոխության հետ կապված, և մեկ մուտքի կետ՝ նոր հասցեն մշակելու և տվյալներ պահանջելու համար: Եթե դա անես ամեն անգամ մի տասնյակ մեթոդներով, ապա դա վատ կոդ կլինի, քանի որ շատ կլինի copy-paste-ը։ Վերոնշյալ ձևով կլինեն երկու մուտքի կետեր և արդյունքում՝ այս հատվածների երկարացման կետեր վեբ հավելվածներ.

Մեկ էջի հավելվածի իրականացում

Վերջում, օգտագործելով հաջորդականությունը / կտտացրեք ակտիվ տարրի վրա -> փոխել uri -> մշակել նոր uri -> պահանջել տվյալներ -> նկարել էջի նոր տարրեր / կարող եք ստեղծել լիովին ֆունկցիոնալ մեկ էջի հավելվածներ. Իմ աշխատանքում ես օգտագործել և բաժանել եմ գրեթե ամեն ինչ դասերի, որոնցից յուրաքանչյուրը վերահսկում էր իր տարածքը:

Գլխավոր հիմնական javascriptսկզբնավորման ֆայլը, որը գործարկում է հավելվածը. Ստեղծվում է նաև հիմնական դասը (օրինակ. մեկ հավելված), որը կառավարում է հավելվածի վիճակը, սկզբնավորում է անհրաժեշտ իրադարձությունները (իրադարձությունները), աշխատում է հետ պատմության օբյեկտ , մշակում և փոխում է url-ը և այլ գործառույթներ: URL-ը ձևավորվում է SEO-ի աջակցությամբ (/category/tech/page/2)՝ համաձայն /key/value/ հայեցակարգի։ Իմ հավելվածում ես նաև օգտագործել եմ , որն ինձ թույլ է տվել նվազեցնել սխալների քանակը, նվազագույնի հասցնել դասի համախմբվածությունը և հեշտացնել աշխատել հետադարձ կապի գործառույթների հետ, որոնց վրա ես կառուցվել եմ: մեկ էջի դիմում.

Ինչ է SPA-ն

«SPA-ն վեբ հավելված է, որը տեղակայված է մեկ էջում, որը բեռնում է բոլոր javascript ֆայլերը (մոդուլներ, վիդջեթներ, հսկիչներ և այլն) և CSS ֆայլերը հենց էջի հետ միասին, որպեսզի այն աշխատի»:

SPA: Կողմ

Առաջին առավելությունն այն է, որ SPA հավելվածները հիանալի են աշխատում ինչպես ստացիոնար, այնպես էլ շարժական սարքերի վրա: «Խոշոր» համակարգիչները, պլանշետները, սմարթֆոնները և, ի վերջո, պարզ հեռախոսները (ոմանք) կարող են ազատորեն աշխատել SPA-ի սկզբունքով կառուցված կայքերի հետ։ Այսպիսով, առաջին «գումարածը»՝ աշխատել մեծ թվով սարքերի վրա, ինչը նշանակում է, որ մեկ հավելված ստեղծելով, դուք ստանում եք օգտատերերի շատ ավելի մեծ լսարան, քան ստանդարտ մոտեցումն օգտագործելիս։

Հետագա երկրորդ «գումարածը» հարուստ ինտերֆեյս է, այսպես կոչված Օգտատիրոջ փորձը։ Քանի որ կա միայն մեկ վեբ էջ, հարուստ, հարուստ ինտերֆեյսի ստեղծումը շատ ավելի հեշտ է: Ավելի հեշտ է պահել նիստի տեղեկատվությունը, կառավարել դիտման վիճակները և կառավարել անիմացիաները (որոշ դեպքերում):

Երրորդ «գումարածը»՝ SPA-ն զգալիորեն (երբեմն) նվազեցնում է այսպես կոչված «շրջանակով քայլելը», այսինքն՝ նույն բովանդակությունը նորից ու նորից ներբեռնելը։. Եթե ձեր պորտալը (կայքը) օգտագործում է ձևանմուշ, ապա ցանկացած էջի հիմնական բովանդակության հետ մեկտեղ կայքի այցելուն պետք է ներբեռնի կաղապարի նշումը: Այո, WWW-ի զարգացման այս փուլում տվյալների քեշավորումը հասել է ամենաբարձր արդյունքների, բայց եթե քեշավորման բան չկա, ապա դրա վրա և՛ ժամանակը, և՛ ռեսուրսները չեն վատնում։

SPA: Դեմ

Եթե դուք ծրագրավորում եք C#-ով, ապա SPA-ի միակ բացասական կողմն այն է, որ դուք պետք է սովորեք JavaScript: Ամեն դեպքում ես չկարողացա գլուխ հանել այլ գլոբալ խնդիրներից։

SPA բաղադրիչներ

SPA-ն աջակցում է հաճախորդների նավիգացիան: Օգտատիրոջ բոլոր «քայլերը» մոդուլ-էջերի միջով միանշանակ գրանցվում են նավիգացիայի պատմության մեջ, իսկ նավարկությունը «խորը» է, այսինքն՝ եթե օգտատերը պատճենում և բացում է ներքին մոդուլ-էջի հղումը մեկ այլ բրաուզերում կամ պատուհանում: , նրան կտեղափոխեն համապատասխան էջ։
SPA-ն գտնվում է մեկ վեբ էջում, ինչը նշանակում է, որ կայքի (պորտալի) աշխատանքի համար անհրաժեշտ բոլոր սցենարներն ու ոճերը պետք է սահմանվեն նախագծում մեկ տեղում՝ մեկ վեբ էջում:
SPA-ն մշտապես պահպանում է հաճախորդի վիճակը (կարևոր փոփոխականները) (հաճախորդի սկրիպտ) բրաուզերի քեշում կամ Web Storage-ում:
SPA-ն բեռնում է բոլոր սկրիպտները, որոնք անհրաժեշտ են հավելվածը սկսելու համար, երբ վեբ էջը սկզբնավորվում է:
SPA-ն աստիճանաբար բեռնում է մոդուլները ըստ պահանջի:

SPA կաղապարներ

ապահովել ԲՀՊՏ-ի զարգացման հիմնական սկզբունքները՝ նվազագույնի հասցնելով աշխատուժի ծախսերը համընդհանուր խնդիրների լուծման համար (տե՛ս «SPA-ի բաղադրիչները» բաժինը.
շրջանակները ստեղծվում են ծրագրավորողների համայնքի կողմից, ինչը նշանակում է, որ նրանք օգտագործում են բազմաթիվ ծրագրավորողների կայքեր ստեղծելու փորձը.
Frameworks-ը մեկնարկային կետն է Single Page Application-ի վրա հիմնված կառուցվածք ստեղծելու համար:

SPA կաղապարի առանձնահատկությունների համեմատություն

Աղյուսակը ցույց է տալիս որպես հիմք մեկ էջի հավելված ստեղծելու ամենատարածված ձևանմուշները: Խնդրում ենք նկատի ունենալ, որ կապույտ ֆոնն ընդգծում է ամբողջական կառուցվածք ստեղծելու հիմնական բլոկները, ինչպիսիք են DurandalJS-ը և HotTowel-ը, որոնք ընդգծված են կանաչով:

Այսպիսով, հետևելով աղյուսակում ներկայացված տվյալներին, դուք կարող եք ստեղծել Single Page Application՝ օգտագործելով մերկ ASP.NET և KnockoutJS: Այնուամենայնիվ, դուք պետք է ինքներդ գրեք տվյալների հետ աշխատելու իրականացումը (DAL), սակայն, ինչպես նաև կառավարեք նավիգացիայի և նավիգացիայի պատմությունը:

Ներածություն

Վերջերս ես հնարավորություն ունեցա առերեսվելու մի նախագծի հետ, որը պետք է ավարտի մեկ անգամ գրված CRM-ը: Վերանայման նպատակն էր բարձրացնել համակարգի կատարողականը օգտատիրոջ հետ շփվելիս և ավելացնել որոշ նոր ֆունկցիոնալություն, ինչպես նաև վերացնել նախորդ մշակողների կողմից հայտնաբերված և JavaScript «e-ում չպարզված հիշողության արտահոսքերը, որոնց վրա ներդրվել է ամբողջ ինտերֆեյսը:
Սկսելով նախագիծը, փորփրելով հսկայական թվով գրադարանների և շրջանակների աղիքները, որոնք օգտագործվում են և ոչ այնքան բարեկամական միմյանց հետ, մի շարք փորձարկումներ կատարելուց հետո մենք եկանք անսպասելի եզրակացության, որ ամեն ինչի մեղավորն էր… SPA - ճարտարապետություն.

Մի քանի խոսք SPA-ճարտարապետության մասին

Խոսելով ժամանակակից վեբի մասին, դուք կարող եք ավելի ու ավելի հաճախ լսել Single Page Application (SPA) տեխնոլոգիայի մասին, թեև ավելի ճշգրիտ լինելու համար, SPA-ն տեխնոլոգիաների մի շարքի հավաքական անվանումն է, որը թույլ է տալիս իրականացնել WEB հավելված, որն իրականացվում է WEB բրաուզերի կողմից որպես ներդրված է մեկ ՎԵԲ էջ, ինչպիսին է, օրինակ, Google-ի Gmail ծառայությունը: Օգտատիրոջ տեսանկյունից, այս տեխնոլոգիանգրավվում է հիմնականում գործողություններին արձագանքելու արագությամբ օգտագործողի ինտերֆեյս, քանի որ այն չի պահանջում սերվերից WEB էջի ամբողջական կամ նույնիսկ մասնակի վերաբեռնում, և բոլոր տեսողական տարրերը կառուցված են անմիջապես բրաուզերում JavaScriptփաստաթղթի DOM կառուցվածքը շահարկելու միջոցով:
Այսպիսով, WEB հավելվածները շատ նման են աշխատանքային կայանների սովորական հավելվածներին, որոնք տեղեկատվություն են ներբեռնում ինտերնետից, միայն դրանց կատարման միջավայրը չէ: օպերացիոն համակարգ, բայց զննարկիչը, որը արդյունքում ստիպված է կրել երրորդ կողմի կոդի կատարման հետ կապված ամբողջ բեռը, մասնավորապես հիշողության կառավարումը, անվտանգ միջավայրի ապահովումը, հետ աշխատելու ֆունկցիոնալությունը: համակարգի գործառույթներըև ապարատային միջավայր և այլն:

SPA-ճարտարապետության կենտրոնական տեղը զբաղեցնում է տեսարանը (View)՝ այն, ինչ տեսնում և շփվում է օգտագործողը: Դիտման արդյունքը դիտարկիչի կողմից ցուցադրվող ամենատարածված HTML-ն է: Ի տարբերություն «անցումային» «WEB 2.0» հավելվածների, որոնք ակտիվորեն աշխատում են փաստաթղթի DOM կառուցվածքի հետ, օրինակ՝ օգտագործելով jQuery կամ ընդգծում, SPA հավելվածն օգտագործում է DOM-ը միայն փոփոխություններ գրելու, բայց ոչ կարդալու, այսինքն՝ չպահելու համար։ տվյալներ. SPA-ի ճարտարապետության մեկ այլ բաղադրիչ այժմ օգտագործվում է տվյալների պահպանման համար՝ մոդելը:

Մոդելը տվյալների և իրադարձությունների մանիպուլյացիայի համար տվյալների, գործառույթների հավաքածու է: Մոդելի բոլոր տվյալները ամբողջությամբ պահվում են հիշողության մեջ: Որպեսզի մոդելի տվյալները և դիտման կողմից ցուցադրվող տվյալները պահպանեն ամբողջականությունը, տեսքը բաժանորդագրվում է մոդելային իրադարձություններին, այդպիսով հետևելով մոդելի տվյալների փոփոխություններին: Իր հերթին, մոդելը նաև արձագանքում է դիտման ծանուցումներին և ապահովում է անխափան կապ վեբ հավելվածի և սերվերի միջև՝ կատարելով տվյալներ ստանալու կամ ուղարկելու հարցումներ (մասնավորապես, օգտագործելով REST մեթոդաբանությունը):

Բայց վերադառնանք շոուն: Ներկայացումը ժամանակակից ԲՀՊՏ-ների ամենակարևոր և ամենաբարդ մասն է: Սովորաբար, դիտումները կառուցվում են այսպես կոչված կաղապարների շուրջ՝ HTML-ի վերածվող դատարկ բացեր: Նաև տեսքը թարմացնում է ստացված HTML-ը, երբ մոդելը փոխվում է և հակառակը - ծանուցում է մոդելին դիտման միջոցով օգտագործողի գործողությունների մասին, օրինակ՝ մկնիկի սեղմումով, ստեղնաշարի մուտքագրմամբ կամ սարքի պտտմամբ, ինչի արդյունքում մոդելը կարող է կատարել տվյալներ։ մանիպուլյացիաներ և այնուհետև նորից ծանուցեք տեսքին տվյալների փոփոխության մասին, որպեսզի դիտումը թարմացվի կամ ստեղծի նոր HTML:
Դասական WEB հավելվածի (կամ WEB կայքի) աշխատանքը ամբողջությամբ կառուցված է տվյալների քեշավորման վրա՝ սերվերի վրա, պրոքսի սերվերի և հաճախորդի վրա: Եթե հավելվածի տվյալները և վիճակը թարմացվում են շատ հաճախ, ապա քեշավորումն օգտագործելու առավելությունը գրեթե բացակայում է: Տեսականորեն, մեկ էջի հավելվածը պետք է օգտագործի ավելի քիչ քեշ, քանի որ տվյալները մեկ-մեկ բեռնվում են: կյանքի ցիկլէջերում, բայց գործնականում դա միշտ չէ, որ այդպես է, և մենք այս մասին կխոսենք ստորև:

CRM-ի առանձնահատկությունները, որոնք չեն տեղավորվում SPA-ի իրականացման մեջ

Տեսնենք, թե ինչպես կարող ենք օգտագործել SPA տեխնոլոգիան՝ հաճախորդների հետ հարաբերությունների կառավարման պարզ համակարգ կամ CRM-ն ներդնելու համար: Մեզ նախ և առաջ հետաքրքրում է տեղեկատվության մշակման գործառնական և վերլուծական մակարդակները:

Եկեք, օրինակ, վերցնենք պարզ CRM-ի բաժինների խիստ պարզեցված հավաքածու.

Desktop (Dashboard) - համակարգի բոլոր տվյալների ամփոփում, որը իմաստ ունի որոշակի օգտագործողի համար:
Միջոցառումներ - դիտեք շուկայավարման, վաճառքի և արտադրության բաժինների օգտագործողների համատեղ գործունեությունը:
Հաճախորդներ - հաճախորդների բազայի, կոնտակտների և ընկերությունների կառավարում:
Նախագծեր և գործարքներ՝ հաճախորդների հետ հարաբերությունների կառավարում:
Առաջադրանքներ - իրականացման աշխատանքների ընթացքի կառավարում:
Հաշվետվություններ - կուտակված տեղեկատվության վերաբերյալ վերլուծական հաշվետվությունների դիտում և կառավարում:
Պրոֆիլ - օգտվողի պրոֆիլի կառավարում:

Յուրաքանչյուր բաժնում օգտագործողը աշխատում է հաճախակի փոփոխվող տվյալների ընտրությամբ: Գործառնական մակարդակում CRM-ի կարևոր պահանջներից մեկը օգտատերերի փոխազդեցության բարձր կատարողականությունն է այնպիսի գործողություններ կատարելիս, ինչպիսիք են տեղեկատվության ռեեստր հաճախակի մուտքը, բարդ զտման ակտիվ օգտագործումը և մեծ քանակությամբ արդյունքների տեսակավորումը: Նաև վերլուծական մակարդակում պահանջվում է արագ ստանալ հաշվետվություններ, վիճակագրություն, վերլուծություններ և կանխատեսումներ տարբեր չափումների և ցուցանիշների վերաբերյալ:

Մեկ էջի հավելվածում էջերի փոխարեն մենք աշխատում ենք «էկրաններով»: Յուրաքանչյուր էկրան մի ենթահամակարգի մի մասն է՝ կաղապարների, մոդուլների, կարգավորիչների, երթուղու և մոդելի իր հավաքածուով: Երբ օգտատերը նավարկվում է հավելվածի մեկ այլ բաժին, բեռնվում են տվյալ բաժնի աշխատանքի համար անհրաժեշտ տվյալները, ձևանմուշները և մոդուլները, մինչդեռ կարևոր է, որ օգտատերը լինի նույն էջում, և ներկայիս վիճակը նոր բեռնման ժամանակ: էկրանը պահպանված է։

Ամբողջ համակարգի ընդհանուր մոդելը բարդ է՝ բաղկացած յուրաքանչյուր էկրանի համար անկախ մոդելներից: Էկրանների միջև անցումը հանգեցնում է ընթացիկ դիտման շերտի մաքրմանը և նոր շերտի ստեղծմանը, որը բավականին հաճախ իրականացվում է այնպես, որ նախորդ շերտը պարզապես անտեսանելի է դառնում, իսկ փոխարենը ցուցադրվում է նորը, այսինքն՝ փոխարկման գործընթացը: Էկրանների միջև դասավորվում է այնպես, որ նախնական բեռնումից հետո պատրաստի դիտումները հետագայում պարզապես թաքցվում և ցուցադրվում են:

Սա շատ տարբեր է դասական եղանակովաշխատել WEB հավելվածի հետ, որտեղ հղումների վրա սեղմելը առաջացնում է էջերի լրիվ ծանրաբեռնվածություն, որն ավտոմատ կերպով առաջացնում է ռեսուրսների թողարկում և տվյալների թարմացում, և օգտագործողը կարող է ակնկալել, որ տվյալները միշտ թարմացված են: CRM-ում արագ փոփոխվող տվյալների համատեքստում, SPA-ի ներդրման ժամանակ օգտագործողի ակնկալիքները հաստատելու համար, էկրանների միջև տեղաշարժվելու գործընթացում անհրաժեշտ է դառնում նաև վերբեռնել բոլոր տվյալները սերվերից, ինչը ժխտում է պահպանման առավելությունը։ հաճախորդի վերաբերյալ բոլոր տվյալները և, հետևաբար, SPA-ի ամենաշատ կառուցվածքների օգտագործումը:

Խնդիրներ, որոնք առաջացել են CRM-ում SPA-ի օգտագործման ժամանակ

SPA տեխնոլոգիան ստիպում է ծրագրավորողին գրել կոդը շատ զգույշ, քանի որ ցանկացած սխալ կամ անտեսում կարող է հանգեցնել հիշողության արտահոսքի, իսկ արդյունքում՝ ամբողջ համակարգի «արգելակների»:

Ինչու է հիշողությունը արտահոսում:

Երկար աշխատանքի ընթացքում հաճախորդի վրա կուտակված տվյալների հսկայական քանակությունը շատ արագ դառնում է անտեղի։ Բայց միևնույն ժամանակ այս տվյալները պահվում են մոդելում, իսկ դիտումները պահվում են փաստաթղթի DOM կառուցվածքում, եթե դուք նպատակաուղղված չեք մաքրում: Մոդելը և DOM-ը «մաքուր» պահելու համար անհրաժեշտ է պարբերաբար կատարել «աղբահանություն», քանի որ այս դեպքում չպետք է ապավինեք ներկառուցված JIT աղբահավաքին, քանի որ օբյեկտների հղումները, որպես կանոն, հասանելի են մնում։ , հետևաբար, նախկինում ստեղծված և այլևս կարիք չունեցող առարկաները դեռ մնում են հիշողության մեջ։ Պետք է նաև հաշվի առնել, որ JavaScript-ում միշտ կա բոլոր հղումները կորցնելու վտանգ, բայց տվյալները չեն մաքրվի։

Ինչու՞ է ամեն ինչ դանդաղում:

Հիշողության արտահոսքը և իրադարձությունների մշակման մեծ թվով բարդ մոդելը հիմնականում հանգեցնում են էջի դանդաղ աշխատանքի: Էկրանից էկրան տեղափոխելիս, յուրաքանչյուրը բացելիս նոր ձևտվյալները բեռնվում են բրաուզերի գործընթացում, ինչպես նաև գործարկվող կոդը (դրամի դեպքում), որը հաճախ ներարկվում է eval () կառուցվածքների միջոցով: Մոդուլային շրջանակները» և SPA-ների կառուցման համար նույնպես ունեն իրենց ենթակառուցվածքը՝ իրենց ծախսերով: Ամենատարածված պատճառը ծրագրավորողների սխալներն ու թերություններն են, որոնք շատ հեշտ է կատարել և չափազանց դժվար է հետևել: Բարդ SPA-ների պրոֆիլավորումն ու վրիպազերծումը թանկ հաճույք է. չնայած այսօր գործիքներն արդեն բավականաչափ հասուն են վրիպազերծման համար, վրիպազերծման բարդությունն աճում է երկրաչափական չափով, քանի որ հավելվածի բարդությունը մեծանում է: Արդյունքում խնդիրը լուծվում է միայն միավորի վրիպազերծման և թեստավորման միջոցով, որն իր հերթին մեծացնում է զարգացման ծախսերը:
Ինչպե՞ս են այս խնդիրները արտացոլվում CRM-ի մշակման մեջ:

CRM մշակելիս մեծ թվով էկրաններ և ձևեր, տարբեր տրամաբանություն՝ կախված օգտատիրոջ տեսակից, նրա իրավունքներից և թույլտվություններից, տվյալների արագ ծերացումը, ամբողջ համակարգի վիճակը պարբերաբար թարմացնելու անհրաժեշտությունը հիմնական գործոններն են, որոնք բարդացնում են զարգացումը։ CRM SPA տեխնոլոգիայի վրա: Բացի այդ, շահագործման ընթացքում տվյալների քանակի ավելացմամբ մոդելն աճում է, և, հետևաբար, ավելանում է տվյալների մշակման ժամանակը, ինչի հետևանքով համակարգը սկսում է դանդաղել նույնիսկ այնտեղ, որտեղ այն ընդունելի էր թեստերում:

«Բազմաթիվ էկրանների» խնդիրը

Ներդիրներով բրաուզերների օգտատերերը, լինելով նույն էջում, հաճախ բացվում են առանձին էջերբրաուզերի առանձին ներդիրների հղումներով՝ դրանք համադրելով մեկ ներդիրում գտնվող հղումների հետ: Ես կցանկանայի ունենալ նմանատիպ հնարավորություն WEB հավելվածի հետ աշխատելիս. օրինակ՝ բացել նախագծի էջը առանձին ներդիրև պահել այն զարկերակի վրա: SPA-ի դեպքում դա նույնպես հնարավոր է, բայց այս դեպքում զարգացման ծախսերը կտրուկ աճում են. այնտեղ, որտեղ էջերի բեռնման դեպքում խնայողություններ են եղել, այժմ գերբեռնվածություն կա, քանի որ յուրաքանչյուր ներդիրում հավելվածը կբեռնի ամբողջ կոդը: այն պետք է աշխատի; SPA-ի՝ որպես մեկ էջանոց հավելվածի իմաստը կորել է, քանի որ ինտերնետ օգտագործողի համար ակնհայտ է, որ բրաուզերում աշխատելիս հղումը պետք է բացի նոր էջ, այլ ոչ թե իրեն սովորական հավելվածի պես պահի։

Այսպիսով, CRM համակարգերի մշակման ժամանակ SPA ճարտարապետությունը, մեր կարծիքով, ավելի քիչ նախընտրելի է, քան տվյալների թարմացման համար AJAX-ի ակտիվ օգտագործմամբ բազմաէջանոց հավելվածի դասական ճարտարապետությունը:

Խնդրի ներկայացումը բավականին ծավալուն ստացվեց, ուստի դրա լուծման մասին պատմությունը կթողնենք առանձին նյութի։ Շնորհակալ եմ բոլորիցդ կարդալու համար, մնացեք հետևողական: