1c reutilizarea valorilor de retur. Module generale. Steagul linkului extern

   Tipărire (Ctrl + P)

Obiectele amplasate în ramurile arborelui de configurare ale modulelor generale sunt destinate plasării în ele a unor texte de funcții și proceduri care pot fi apelate de la orice alt modul de configurare.
ATENȚIE! Un modul comun poate conține doar definiții ale procedurilor și funcțiilor.
  Procedurile și funcțiile modulului general, pentru care este indicat cuvântul cheie Export în titluri, fac parte din contextul global. Puteți afla mai multe despre procedurile de scriere în modulul general în secțiunile „Formatul codului sursă al modulelor software” și „operatorii” din ajutorul de limbaj încorporat.
  Pentru a edita un modul general, în paleta de proprietăți a obiectului de tip Module generale din fereastra Configurare, în proprietatea Modul, faceți clic pe linkul Deschide. Textul modulului general va fi emis pentru editare în editorul de text al sistemului 1C: Enterprise în modul de editare a textului modulului software.
  Modulul comun, făcând parte din configurație, este salvat doar ca parte a configurației.
  Proprietatea globală stabilește dacă metodele exportate ale modulului general fac parte din contextul global.
  Dacă proprietatea globală este setată pe True, atunci metodele exportate ale modulului comun sunt disponibile ca metode de context global.
  Dacă proprietatea globală este setată pe Fals, atunci în contextul global, o proprietate este creată cu un nume care corespunde numelui modulului comun din metadate. Această proprietate este de numai citire. Valoarea acestei proprietăți este obiectul GeneralModule. Metodele exportate ale acestui modul general sunt disponibile prin intermediul acestui obiect. Astfel, apelul la metode de module comune non-globale arată ca XXXXX.YYYYY, unde XXXXX este numele proprietății care se potrivește cu contextul modulului comun, iar AAAA este numele metodei exportate a modulului comun.
  Un exemplu:

Lucrați cu echipamente comerciale. Conectați codurile de bare ale scanerului ();

Context diferit și module generale

Folosind proprietățile modulelor comune și instrucțiunile preprocesorului, puteți organiza execuția diferitelor metode de module comune în contextul potrivit.
  Fiecare proprietate a unui modul comun este responsabilă de capacitatea de a compila (și executa) un modul comun într-un anumit context.
  Sunt disponibile următoarele proprietăți care sunt responsabile pentru contextul în care sunt disponibile metodele comune ale modulului:
● Client (aplicație obișnuită) - metodele modulului general vor fi disponibile pentru un client gros în modul unei aplicații obișnuite;
  ● - metodele comune ale modulului vor fi disponibile atât pentru clientul subțire, pentru clientul web, cât și pentru clientul gros
  modul de aplicare gestionat;
  ● Server - metodele modulului general vor fi disponibile pe server;
● Conexiune externă   - Metodele comune ale modulului vor fi disponibile într-o conexiune externă.
  Dacă sunt setate mai multe proprietăți în același timp, aceasta înseamnă că metodele modulului comun vor fi disponibile în mai multe contexte.
  Dacă modulul general are proprietatea Server și alte seturi de proprietăți, atunci acest lucru înseamnă că modulul general va fi disponibil simultan pe server și în clientul selectat. Este necesar să înțelegem că de fapt vor fi mai multe versiuni ale codului compilat (în funcție de numărul de clienți selectați și de fapt pentru server).
  Mai mult, dacă metoda localizată într-un astfel de modul comun este apelată de la client, atunci va fi utilizată o copie a clientului a modulului comun, iar dacă este de la server, serverul. În acest caz, folosind directive de preprocesor (a se vedea aici pentru detalii), puteți „proteja” serverul de codul care nu poate fi executat pe acesta.
  Luați în considerare un exemplu. Modulul general (care poate fi executat pe clientul subțire și pe server) are o metodă care are un comportament ușor diferit pe partea clientului subțire și pe partea serverului. Să vedem cum se poate face acest lucru:

#Dacă ThinCustomer Apoi
// Arată avertisment
ShowUser Alert(„Pe client”);
# ENDIF
KonetsProtsedury
  Apoi, pe server, codul va lua următoarea formă:
procedură Metoda modulului general ()   exporturi
// Aici se plasează diversul cod important
KonetsProtsedury
  Iar pe partea subțire a clientului, codul va arăta astfel:
GeneralModule Method () Procedura de export
// Aici se plasează diversul cod important
// Arată avertisment
  ShowUser Alert („On Client”);
KonetsProtsedury

Există mai multe moduri de a transfera controlul de la client la server:
  ● apelați metoda modulului comun al serverului;
  ● într-un modul sau un modul de comandă, apelați la o metodă precedată de directive de compilare & OnServer și & OnServerWithout Context

În același timp, este imposibil să apelați la metode ale modulelor comune ale clientului (pentru care proprietatea Server nu este setată) și la metodele client ale modulului formular sau ale modulului de comandă din procedurile serverului. Managementul va reveni la client după ce cel mai extern apel de metodă a serverului a fost finalizat.
  O excepție o reprezintă metodele modulului formular și a modulului de comandă, care sunt precedate de directive de compilare & Pe client pe server, & Pe client pe server fără context
De asemenea, trebuie menționate următoarele puncte:
  ● Dacă un modul comun este disponibil pentru mai mulți clienți, atunci când scrieți codul programului, trebuie să țineți cont de restricțiile maxime care pot fi impuse de clienți sau să utilizați instrucțiuni preprocesoare pentru „izolarea” codului specific unui anumit client.
  ● Instrucțiunile preprocesorului au sens și atunci când un modul comun are mai multe contexte de execuție, de exemplu, o conexiune externă și un client subțire sau (care este mult mai comun) un client și server. În acest caz, instrucțiunile preprocesorului vor încadra codul interactiv care nu poate fi utilizat pe server, dar posibil pe client (vezi exemplul de mai sus).
  Pentru mai multe informații despre instrucțiunile preprocesorului și directivele de compilare, consultați secțiunea „Executarea procedurilor și funcțiilor” din ajutorul de limbaj încorporat.
  Proprietatea de apelare a serverului este utilizată pentru a controla capacitatea de a apela la metodele exportate ale modulului serverului comun din codul clientului.
  Dacă proprietatea este setată, atunci metodele exportate ale modulului comun din partea serverului sunt disponibile pentru apelarea de la client. Dacă proprietatea nu este setată, atunci aceste metode exportate pot fi numite numai din metode server (atât metode de modul comun de server, cât și metode de server ale modulului formular și module de comandă).
Consiliul. Se recomandă să setați proprietatea Call server pe False în cazurile în care modulul comun al serverului conține metode care nu sunt de dorit să apeleze de la client (de exemplu, din motive de securitate).
remarcă. Dacă proprietățile sunt setate în același timp Client (aplicație obișnuită), Client (aplicație gestionată), Conexiune externă, apoi proprietatea apelului serverului este resetată automat. Dacă proprietatea apelului serverului este setată, proprietățile sunt resetate automat Client (aplicație obișnuită), Client (aplicație gestionată)   și Conexiune externădacă aceste proprietăți au fost setate în același timp.
  proprietate privilegiat   proiectat pentru a dezactiva controlul accesului atunci când executați metode ale modulului general.
  NOTĂ. Dacă proprietatea privilegiat   instalat, apoi proprietatea Server este setată automat pe modulul general și restabilele proprietăți sunt resetate ( Client (aplicație obișnuită), Client (aplicație gestionată)   și B conexiune externa). Un modul partajat privilegiat poate fi executat doar pe server.

Reutilizarea valorilor de returnare

Dacă modulul comun nu este global, atunci proprietatea Reutilizarea valorilor returnate devine disponibilă. Această proprietate poate lua următoarele valori:
  ● Nu folosiți - nu se folosește reutilizarea valorilor de retur pentru funcțiile acestui modul general.
● La momentul apelului și la momentul sesiunii - se utilizează metoda pentru determinarea reutilizării datelor pentru modulul general. Esența acestei metode este că în timpul executării codului, sistemul își amintește parametrii și rezultatul funcțiilor după primul apel de funcții. Când funcția este apelată din nou cu aceiași parametri, valoarea stocată este returnată (de la primul apel) fără a executa funcția în sine. Dacă o funcție schimbă valorile parametrilor în timpul execuției sale, atunci apelarea din nou a funcției nu o va face.
  Se pot distinge următoarele caracteristici ale salvării rezultatelor apelurilor:
  ● dacă funcția este executată pe server și apelată din codul serverului, valorile parametrilor și rezultatul apelului sunt amintite pentru sesiunea curentă din partea serverului;
  ● dacă funcția este îndeplinită pe un client gros sau subțire, valorile parametrilor și rezultatele apelului sunt stocate pe partea clientului;
  ● dacă funcția este realizată pe partea serverului și este apelată de la codul client, atunci parametrii apelului sunt amintiți atât de partea clientului, cât și de partea serverului (pentru sesiunea curentă).
  Valorile salvate sunt șterse:
  ● dacă proprietatea este setată pe durata unui apel:
  ● pe partea serverului - când controlul este returnat de pe server;
  ● din partea clientului - la finalizarea unei proceduri sau a unei funcții a unui limbaj încorporat de nivel superior (numit de sistem din interfață și nu dintr-o altă procedură sau funcție a limbajului încorporat);
  ● dacă proprietatea modulului comun este setată pe Timpul sesiunii:
  ● pe partea de server - la sfârșitul sesiunii;
  ● pe partea clientului - la închiderea aplicației client.
  Valorile salvate vor fi șterse:
  ● pe server, într-un client gros, într-o conexiune externă, într-un client subțire și într-un client web cu viteza de conectare obișnuită - 20 minute după calcularea valorii stocate sau 6 minute după ultima utilizare;
  ● la clientul subțire și la web cu o viteză de conectare scăzută - la 20 de minute după calcularea valorii stocate;
  ● cu lipsa RAM în fluxul de lucru al serverului;
  ● la repornirea fluxului de lucru;
  ● Când treceți un client la un alt flux de lucru.
  După ștergerea valorilor, apelul funcției exportate este efectuat ca în primul apel.
  Această proprietate a modulelor comune nu afectează executarea procedurilor - procedurile sunt întotdeauna executate.

Dacă modulul general a setat reutilizarea valorilor de retur, atunci tipurile de parametri ale funcțiilor exportate sunt supuse mai multor restricții. Tipurile de parametri pot fi doar:
  ● Tipuri primitive ( Nedefinit, NULL, Boolean, Număr, Șir, Data).
  ● Orice referințe la obiectele bazei de date.
  ● Structuri cu valori de proprietate ale tipurilor de mai sus. În acest caz, identitatea parametrilor este controlată „în funcție de conținutul” structurilor.
  Dacă funcția exportată returnează un obiect, atunci se va returna o referință la obiectul stocat în cache. Dacă, după primirea acestei legături, starea obiectului se schimbă, atunci un apel ulterior către aceeași funcție va returna legătura către obiectul deja modificat fără a efectua efectiv funcția. Acest comportament va fi observat până la ștergerea valorii stocate (din orice motiv). Cu alte cuvinte, o modificare a stării unui obiect obținut ca urmare a unui apel funcțional dintr-un modul comun cu utilizarea repetată a valorilor returnate nu este o bază pentru un apel efectiv al funcției. Ar trebui să vă amintiți, de asemenea, că memoria cache a obiectelor returnate este indiferentă
  starea modului privilegiat în momentul apelului funcțional cu utilizarea repetată a valorilor returnate. Această caracteristică poate duce la următorul comportament:
  ● Executarea efectivă a unui apel funcțional cu utilizarea repetată a valorilor de retur (primul apel) a fost efectuată atunci când este activat modul privilegiat.
  ● La executarea funcției, a fost primit un obiect care nu poate fi obținut cu modul privilegiat dezactivat.
  ● Apelurile funcționale ulterioare au fost efectuate fără a seta modul privilegiat.
  ● Cu toate acestea, până când ștergerea memoriei cache a obiectelor returnate sau repetarea apelului propriu-zis, funcția va returna un obiect formal inaccesibil.
  ● Comportamentul invers este valabil și atunci când primul apel este efectuat fără a seta modul privilegiat, iar în modul privilegiat obiectul care ar putea fi primit în modul privilegiat nu este returnat.

Dacă modulul comun are o proprietate Reutilizarea valorilor de returnare   setat pe durata unei sesiuni, atunci valorile de tip nu pot fi utilizate în valorile returnate de funcțiile unui astfel de modul Manager de tabel temporar.
Dacă o funcție a unui modul comun, cu set de reutilizare, este apelată din același modul general (de exemplu, cu numele CommonModule), ar trebui să vă amintiți următoarea caracteristică: dacă o funcție este denumită de numele MyFunction (), atunci funcția va fi executată de fiecare dată când funcția este apelată . Pentru a utiliza valorile stocate, funcția ar trebui să fie numită cu numele său complet:
CommonModule.MoyFunction ().
  Metoda contextului global șterge toate valorile reutilizabile, atât din partea serverului, cât și din partea clientului, indiferent de locul în care este apelată metoda. După executarea metodei Valorări actualizate ()   primul apel funcțional va fi complet executat.

Module generale 1C   - un obiect de configurare de metadate 1C 8.3 și 8.2, care stochează codul programului, care este adesea numit în configurație. O funcție / procedură poate fi apelată de oriunde în configurație (dacă este exportată).

Cum se utilizează un modul comun

Este o practică bună să plasați o procedură sau o funcție într-un modul comun dacă este apelată în mai multe locuri. În primul rând, dacă procedura este ajustată, ea trebuie corectată doar într-un singur loc. În al doilea rând, acest lucru realizează o ordine mai mare în cod.

Un exemplu tipic de modul general este procesarea unei tranzacții într-un anumit registru, obținerea diferenței în zile lucrătoare, conversia ratelor valutare, conversia cantității / prețului / sumei din secțiunea tabulară și a altor funcții.

Proprietăți comune ale modulului

Una dintre principalele caracteristici ale modulelor comune de la alte module este că nu puteți declara variabile partajate.

Obțineți gratuit 267 de lecții video 1C:

Să analizăm mai detaliat paleta de proprietăți ale modulului general:

• la nivel mondial   - dacă este setat steagul, funcțiile și procedurile din acest modul devin disponibile într-un context global. Ie ele pot fi apelate oriunde în configurație, accesând fără numele unui modul comun. Cu toate acestea, se adaugă o condiție - numele procedurilor și funcțiilor din acest modul general trebuie să fie unic în contextul global.
• server de   - Procedurile și funcțiile acestui modul general pot fi efectuate pe server.
• Conexiune externă   - codurile de program ale acestui modul general pot fi executate atunci când sunt conectate la o sursă externă (de exemplu, COM).
• Client (aplicație gestionată)   - procedurile și funcțiile acestui modul general pot fi utilizate la un client gros într-un mod de aplicare gestionat.
• Client (aplicație obișnuită)   - codurile de program din acest modul general pot fi utilizate la un client gros într-un mod de aplicație obișnuită.
• Apel server   - un steag care permite clientului să folosească procedurile și funcțiile din acest modul general.
• - dacă True este setat, verificarea autorizației va fi dezactivată în acest modul general.
• reciclare   - determină setările valorilor returnate, dacă opțiunea este activată, atunci după prima execuție, sistemul va aminti valoarea pentru parametrii de intrare date și va returna valoarea finalizată. Poate lua următoarele valori: nu este folosit   - oprire, în timpul apelului   - pe durata unei anumite proceduri, pe toată durata sesiunii   - până când utilizatorul a închis sesiunea (programul).

Dacă începeți să învățați programarea 1C, vă recomandăm cursul nostru gratuit (nu uitați

Articolul continuă ciclul „Primii pași în dezvoltarea pe 1C”, analizează în detaliu următoarele aspecte:

• Ce este un modul software și din ce secțiuni este format?
• Pentru ce este modulul de aplicație? De ce sunt doi? Când se execută? Care sunt subtilitățile muncii?
• Ce evenimente sunt asociate cu pornirea sistemului, cum și unde să le procesăm?
• Pentru ce este modulul de conectare extern? Când și cum să-l folosești?
• Când se utilizează modulul de sesiune?
• Ce sunt modulele generice? Care sunt proprietățile și regulile sale de lucru? De ce să folosiți proprietatea „Reutilizarea valorilor de returnare”?
• Când se utilizează modulul formular și ce evenimente pot fi procesate?
• Pentru ce este destinat modulul obiect? În ce secțiuni constă? Cum să vizualizați evenimentele modulului disponibile?
• Ce subtilități de lucru există cu modulele managerului de valori (pentru constante) și modulele de seturi de înregistrări (pentru registre)?
• Care sunt diferențele dintre modulul obiect și modulul manager? Când să-l folosești pe acesta din urmă?

aplicabilitate

Articolul discută despre platforma 1C: Enterprise 8.3.4.496. Materialul este relevant pentru versiunile curente ale platformei.

Module în 1C: Enterprise 8.3

Modulele sunt acele obiecte în care este conținut codul programului.

În platformă există un număr destul de mare de tipuri de module, fiecare având propriile scopuri și caracteristici.

Orice linie de cod ar trebui să fie într-un modul. Distingeți între modulele de scop general și modulele de obiect. Unele module pot fi compilate atât pe Client cât și pe Server, iar altele doar pe Server.

Un modul poate consta din mai multe secțiuni. Secțiunea de descriere a variabilelor descrie variabilele locale ale acestui modul, care pot fi ulterior utilizate în orice procedură.

În cadrul fiecărei proceduri, puteți accesa o variabilă a modulului. În plus, în interiorul procedurii în sine, poate exista o altă declarație variabilă cu același nume. Aceasta va fi variabila locală a acestei proceduri.

În ciuda aceluiași nume, acestea sunt două variabile diferite: una este utilizată în cadrul unei proceduri specifice, iar cealaltă în afara ei.

În unele module, locația compilării (disponibilitatea) pe Server sau pe Client poate fi indicată pentru variabile. De exemplu:

Secțiunea pentru descrierea variabilelor este urmată de secțiunea de proceduri și funcții, unde sunt indicate metodele locale ale acestui modul. Unele module ar trebui să indice unde se va compila procedura sau funcția.

În principiu, directiva de compilare poate fi omisă. În acest caz, directiva de compilare implicită este Server. Cu toate acestea, pentru comoditatea analizării codului programului, se recomandă să indicați în mod explicit unde va fi compilată această procedură. Ordinea în care sunt descrise procedurile nu contează.

La sfârșitul modulului, după descrierea tuturor procedurilor și funcțiilor, există o secțiune a programului principal, unde pot fi conținuți unii operatori și sunt inițializate variabilele locale ale modulului formular. Această secțiune este executată la accesarea modulului.

Deci, de exemplu, atunci când deschidem forma unui element, în primul rând, se execută secțiunea programului principal al modulului formular.

Trebuie menționat că secțiunea de declarare variabilă și secțiunea principală a programului nu există pentru toate modulele (adică, în unele module, aceste secțiuni nu sunt permise). Secțiunea care descrie procedurile și funcțiile poate exista în absolut orice modul.

Modulul de aplicare

Acest modul este proiectat pentru a gestiona evenimentele de lansare și completare a aplicației. De exemplu, când porniți aplicația, puteți descărca cursurile de schimb de pe Internet. La sfârșitul aplicației, puteți verifica cu utilizatorul intențiile sale de a finaliza lucrarea.

De asemenea, în modulul de aplicații există manipulatoare speciale care vă permit să interceptați evenimente externe din echipament.

Poate fi evenimente de la un cititor de carduri magnetice, un registrator fiscal. Și aceste evenimente pot fi gestionate într-un fel.

Trebuie menționat că lansarea sistemului interactiv este monitorizată în modulul de aplicație.

Modulul de aplicație nu va funcționa dacă programul 1C este lansat, de exemplu, în modul de conectare com. În acest caz, fereastra programului nu este creată.

Trebuie menționat că în Platforma 8.3 există două module de aplicații diferite: un modul de aplicație gestionat și un modul de aplicație Normal. Evenimentele modulului de aplicație gestionat sunt procesate la lansarea clientului Thin and Thick din aplicația Managed și a clientului Web.

modul Aplicare regulată   funcționează atunci când porniți clientul gros în modul Aplicare regulatăîn care există o interfață de comandă regulată în formular Meniul principal.

Dacă aplicația rulează gestionate, și în Aplicare regulată, este necesar să se descrie procedurile de manipulare ca pentru modul Aplicație gestionatădeci pentru modul Aplicare regulată.

modul Aplicație gestionată   poate fi selectat din meniul contextual al nodului de configurare rădăcină.

De asemenea, puteți deschide acest modul din paleta de proprietăți a elementului de configurare rădăcină.

Pentru a deschide modulul Aplicare regulată, trebuie să vă referiți la setările de configurare (comandă parametriiîn meniu serviciu).

Formularul se va deschide parametrii. Pe marcaj comuntrebuie specificat modul de editare a configurației Aplicație gestionată   și Aplicare regulată.

În acest caz, modulul Aplicare regulată   poate fi deschis și din proprietățile nodului rădăcină.

Lista evenimentelor pentru care pot fi procesate gestionateși Aplicare regulată   la fel.

În acest modul, puteți plasa o secțiune pentru declararea variabilelor, o secțiune pentru descrierea procedurilor și funcțiilor arbitrare și o secțiune pentru programul principal. Dar, pe lângă procedurile și funcțiile arbitrare, în modul pot fi amplasate instrumente speciale de gestionare a evenimentelor.

Puteți vedea lista operatorilor disponibili dacă apelați la lista de proceduri și funcții ale modulului curent când modulul este deschis.

Fereastra Proceduri și Funcții care se deschide afișează toate procedurile și funcțiile acestui modul, precum și evenimente pentru care nu au fost încă create gestionarele.

Există două evenimente legate de pornirea sistemului („înainte” și „când”). Două evenimente legate de oprirea sistemului („înainte” și „când”). De asemenea, procesarea evenimentelor externe (de exemplu, evenimente de comercializare a echipamentelor).

Când se execută gestionarul de evenimente „înainte”, se consideră că acțiunea nu a fost încă finalizată. Când gestionatorul de evenimente „când” este executat, acțiunea a fost deja finalizată.

eveniment Înainte de a începe sistemeleapare în momentul lansării Enterprise 8.3, dar aplicația însăși nu a apărut încă pe ecran. Acest eveniment are un parametru cum ar fi eșec.

Dacă acest parametru devine Adevărulatunci aplicația nu va începe. eveniment ÎNCEPEȚI Sistemelepresupune că acțiunea a fost deja finalizată, fereastra a fost deja creată și, în acest caz, putem afișa, de exemplu, o formă specială. Nu mai este posibil să refuzi lansarea.

În mod similar, înainte de închiderea sistemului, aplicația este încă deschisă și puteți refuza completarea acesteia. Când sistemul se oprește, fereastra aplicației s-a închis deja. Este posibil să efectuați numai acțiuni suplimentare, de exemplu, pentru a șterge anumite fișiere sau a trimite un e-mail.

În modul Aplicație gestionată   directivele pentru compilarea procedurilor și funcțiilor nu sunt indicate, deoarece modulul este complet compilat pe partea de Client. Aceasta înseamnă că în procedurile și funcțiile modulului nu vom putea accesa direct, de exemplu, cărți de referință.

Dacă din modul Aplicație gestionată   trebuie să efectuați un apel la server, atunci pentru aceasta va trebui să creați special   cu setul de pavilion .

În modul Aplicare regulată   Nu există astfel de restricții, deoarece acest modul va fi compilat la încărcarea Thick Client. În Fat Client, aproape toate tipurile de date sunt disponibile.

Procedurile, funcțiile și variabilele modulului de aplicație pot fi descrise ca fiind exportate.

Deoarece modulul a fost compilat integral pe Client, acest lucru înseamnă că în procedurile clientului ne putem referi la această metodă și la această proprietate.

De exemplu, din modulul formular al unui obiect, puteți apela procedura sau funcția modulului de aplicație. Cu toate acestea, este recomandat să utilizați Module comune pentru a descrie algoritmi comuni. Scopul principal al modulului de aplicare este procesarea punctului de pornire și a punctului final.

Prin analogie cu modulul de aplicație, acest modul este conceput pentru a gestiona evenimentul deschis program și evenimentul de oprire.

Spre deosebire de modulul de aplicație, care este inițiat în momentul lansării interactive a aplicației, modulul de conexiune externă funcționează în modul conexiune simultană, adică. când obiectul 1C: Enterprise 8 este creat și se face o conexiune la o bază specifică.

Există evenimente în acest modul: ÎNCEPEȚI Sistemeleși După finalizarea sistemului.

Un modul extern de conexiune poate fi deschis folosind fie meniul contextual la nivelul obiectului de configurare rădăcină, fie paleta de proprietăți pentru nodul rădăcină.

Procesul de conexiune externă este un proces de lucru al programului cu o bază de informații, și nu una interactivă. În consecință, în acest moment nu puteți utiliza formulare de dialog sau afișa mesaje de avertizare, deoarece nu există o interfață de utilizator.

În modulul de conexiune externă, este posibilă descrierea variabilelor de export și a metodelor de export care vor fi disponibile pe partea în care se efectuează apelul extern 1C: Enterprise 8.3.

Deoarece nu există nicio interfață de utilizator în conexiunea externă, modulul de conexiune externă este compilat în întregime pe server.

Modul de sesiune

Acest modul este necesar pentru inițializarea parametrilor sesiunii. Parametrii sesiunii sunt variabile globale rapide ale căror valori sunt disponibile oriunde în configurație.

Puteți deschide modulul de sesiune fie prin meniul contextual, fie prin paleta de proprietăți ale nodurilor rădăcină.

Modulul de sesiune oferă un eveniment Setarea setărilor sesiunii.

Când începe aplicația, această procedură se numește chiar prima. Parametrii sesiunii sunt necesari în timpul oricărei operații a aplicației: atât în \u200b\u200btimpul lansării interactive, cât și la pornirea în modul de conectare externă.

Modulul sesiunii descrie diferitele acțiuni de inițializare a parametrilor sesiunii, în funcție de condiții diferite.

Acest modul, de regulă, descrie mai multe proceduri care sunt apelate de la o procedură Setarea setărilor sesiunii. Prin urmare, toate aceste proceduri sunt alocate într-un modul separat.

Modulul de sesiune este întotdeauna executat în modul privilegiat. Aceasta înseamnă că controlul accesului nu va fi efectuat la accesarea bazei de date. Modulul de sesiune este compilat pe server, adică. este posibil să accesați orice metode server (inclusiv citirea valorilor din baza de date).

În modulul de sesiune, este posibilă definirea numai a procedurilor și a funcțiilor, adică. nu există o secțiune care să descrie variabile și nici o secțiune a programului principal. Nu puteți descrie metode de export în modulul de sesiune.

Dacă la pornirea sistemului este necesar să efectuați unele acțiuni pe Server, de exemplu, pentru a crea un element al unui director, atunci, ca opțiune, este posibil să utilizați modulul de sesiune, ca este compilat pe server și este întotdeauna executat în mod fiabil la pornirea sistemului. Cu toate acestea, trebuie luate în considerare următoarele puncte:

• procedura Setarea setărilor sesiuniise efectuează nu numai la pornirea sistemului, ci și la accesarea parametrilor de sesiune neiniționați. Ie handler-ul de setare a parametrilor de sesiune poate fi apelat în mod repetat în timpul funcționării aplicației;
• dacă numărul de elemente din tabloul parametrilor sesiunii este zero (tabloul parametrilor necesari are tipul de date Nedefinit), acesta este momentul în care începe aplicația;
• întrucât modulul de sesiune operează în modul privilegiat și nu va fi verificată drepturile de acces, este necesar să lucrați foarte atent cu obiectele bazei de date, deoarece utilizatorul poate accesa datele care nu ar trebui să i se furnizeze;
• când sistemul pornește, nu se știe cu siguranță dacă aplicația va fi lansată. În același timp, în gestionarea evenimentelor pentru setarea parametrilor sesiunii, se pot efectua acțiuni inutile.

Aceste module sunt o descriere a unor algoritmi obișnuiți, adică. proceduri și funcții care pot fi apelate din diverse locuri.

Metodele legate logic pot fi grupate în diferite module generale. Aceste module sunt create în cadrul sucursalei generale.

Puteți adăuga orice număr de module comune. Pentru ca metodele modulelor generale să fie disponibile în alte locuri din configurație, trebuie să le definiți cu cuvântul cheie Export. Procedurile client ale modulelor comune vor fi disponibile pe Client, iar procedurile serverului pe Server.

În modulele generale, este disponibilă doar secțiunea care descrie procedurile și funcțiile. Ie în modulul General, nu puteți descrie variabile și nu puteți descrie o secțiune a programului principal.

Dacă aveți nevoie de o variabilă globală, puteți utiliza fie parametri de sesiune, fie variabile de export ale modulului de aplicație.

Pentru modulele generale, puteți seta câțiva parametri care vor afecta comportamentul acestui modul. Dacă proprietatea globală este setată pentru modulul general, atunci metodele de export declarate în acest modul vor fi disponibile direct din exterior fără alte instrucțiuni suplimentare.

Ie Modul general   va participa la formarea contextului global de configurare.

proprietate la nivel mondialpentru module generale pot fi utile. Cu toate acestea, nu ar trebui să îl utilizați universal pentru toate modulele comune.

aceia marcat cu la nivel mondialva fi compilat la pornirea sistemului. Cu cât sunt mai multe astfel de module, cu atât programul va începe mai lent.

Dacă drapelul la nivel mondialpentru Modul generalnespecificate, atunci compilarea acestui modul va fi efectuată la momentul primului apel (adică după începerea sistemului).

În plus, utilizarea modulelor comune globale afectează înțelegerea codului. Metodele generice non-globale sunt numite folosind numele Modul general   și numele metodei, de exemplu:
Modul de costuri Distribuie costuri indirecte ();

Numele modulelor generale ar trebui să reflecte conținutul procedurilor descrise în acestea. Specificarea numelui modulului general la apelarea procedurii contribuie la o mai bună înțelegere a codului.

pentru Modul general   în Paleta de proprietăți   poate seta proprietatea privilegiat.

Modulul privilegiat nu controlează drepturile de acces. Acest lucru este necesar în cazul în Modul comun   Este necesară efectuarea procesării în masă a datelor, primind date din baza de date.

Controlul accesului crește timpul necesar pentru a accesa baza de date, iar algoritmii de masă trebuie să lucreze cât mai repede posibil.

De exemplu, o operațiune care consumă resurse este salarizarea. Trebuie completat cât mai repede posibil. Pentru aceasta, algoritmi care calculează salariile sunt plasate în privilegii .

Mai mult, toate procedurile care asigură completarea documentelor de salarizare sunt în afara acestora Module comune. În aceste proceduri se efectuează controlul accesului.

În acest fel, se poate obține o creștere semnificativă a performanței. Acest lucru este valabil mai ales în cazul aplicării mecanismului controlului de acces linie la linie la intrările din tabel.

Dacă modulul General este privilegiat, atunci procedurile acestui modul pot fi compilate doar pe Server.

Există situații când un obiect trebuie să fie inaccesibil pentru utilizator, de exemplu, un director specific. Dar atunci când se realizează un singur document, este necesară trimiterea la acest director.

Ie este necesar să extindeți temporar drepturile utilizatorului, apoi să le returnați la starea inițială. Acest efect poate fi obținut utilizând privilegiați Module comune.

Pentru asta în privilegiat Modul comun   ar trebui să elaboreze o procedură care se referă la datele dorite.

Această procedură va fi apelată din documentul corespunzător. Ie în momentul apelării acestei proceduri, utilizatorului i se acordă de fapt drepturi extinse.

pentru Module comune   Este posibil să se indice locul compilării. Cu ajutorul indicatorilor este setat: dacă modulul General va fi disponibil pe Client (aplicația gestionată), pe Server, în modul de operare al conexiunii externe.

În plus, dacă treceți modul de editare a configurației la o aplicație administrată și o aplicație obișnuită, va fi posibil un alt context de compilare - Client (aplicație obișnuită).

Astfel, există patru opțiuni pentru funcționarea programului. În funcție de aplicația rulată, în funcție de lucrările efectuate de Client sau de Server, anumite module generale vor fi disponibile sau inaccesibile.

Pe lângă capacitatea de a specifica stegulețe de compilare, este posibil să specificați directive de compilare pentru proceduri și funcții situate în modulul General.

Dacă este specificată o directivă de compilare pentru o metodă, deși modulul General este disponibil în toate contextele specificate, disponibilitatea unei anumite metode va fi limitată de directiva de compilare.

Cu toate acestea, procedura poate să nu fie disponibilă într-un context care nu este disponibil în general pentru întregul modul.

Dacă directiva de compilare a procedurii (funcției) nu este specificată, atunci va fi compilată în toate contextele definite pentru modul.

Ie de fapt, se vor face mai multe copii ale procedurii. Alegerea unei instanțe compilate specifice depinde de locația apelului de procedură (conform regulii celui mai apropiat apel). Trebuie avut în vedere faptul că codul unei astfel de proceduri ar trebui să fie scris ținând cont de disponibilitatea acestuia în toate contextele definite pentru modul.

Modulele generale care sunt disponibile simultan în mai multe contexte diferite sunt destinate în principal să creeze proceduri care sunt disponibile în mai multe contexte.

La crearea unui modul general, se consideră o bună practică să nu se specifice directivele de compilare. Ie disponibilitatea procedurilor și funcțiilor ar trebui să fie determinată de proprietățile modulului în sine.

Cu această abordare, procedurile client vor fi localizate în module generale separate și proceduri server în module generale separate.

Modulele cu mai multe indicatoare de compilare setate sunt rareori utilizate în practică. Acestea sunt câteva acțiuni comune disponibile atât pe Client cât și pe Server. De obicei, acestea sunt câteva calcule simple.

Important! Este posibil să accesați metodele serverului de export ale modulului General de la Client, dar numai dacă acest modul General este compilat doar pe Server. În același timp, este oferit un steag special pentru a oferi acces din partea Clientului .

Pentru modulele generale care nu sunt globale, este posibilă memorarea în cache a valorilor returnate de funcții. Ie după primul apel funcțional, sistemul își poate aminti rezultatul execuției sale. Dacă această funcție este apelată din nou cu aceiași parametri, sistemul va returna valoarea deja din cache.

Scopul acestui mecanism este acela de a accelera apelurile repetate. Pentru a configura acest comportament, trebuie să Paleta de proprietăți   modulul pentru a seta valoarea corespunzătoare pentru proprietatea Reutilizarea valorilor de retur.

În mod implicit, această proprietate este setată pe Nu utilizați. Alte valori posibile: cache În timpul apeluluisau Pe toată durata sesiunii.

Este logic să folosiți această proprietate doar pentru acele funcții al căror rezultat depinde exclusiv de parametrii de intrare. Acest mecanism este disponibil numai pentru modulele generale non-globale.

Dacă valoarea parametrului corespunzător La momentul selectării apelului, memoria cache va rămâne activă până când se execută procedura de la care a fost făcut apelul către metoda modulului general. Dacă valoarea În timpul sesiunii este selectată, atunci se consideră condiționat că memoria cache va acționa în timp ce utilizatorul lucrează.

Cu toate acestea, există anumite termene. Ștergerea memoriei cache se produce automat la 20 de minute după ce valoarea atinge memoria cache.

Modul formular

Acest modul este proiectat pentru a procesa acțiunile utilizatorilor. De exemplu, descrieți algoritmul de reacție al unui program atunci când este apăsat un buton. Sau, de exemplu, în momentul introducerii valorii în câmp, verificați imediat corectitudinea.

Pe lângă evenimentele asociate cu controale de formular (butoane, câmpuri de introducere), există evenimente legate direct de formularul în sine.

De exemplu, puteți gestiona eventualitatea deschiderii formularului și puteți efectua o inițializare inițială. De asemenea, puteți gestiona evenimentul de închidere a formularului și verificați dacă utilizatorul a introdus totul corect.

Există forme controlabile și forme obișnuite. Modulele acestor forme diferă în primul rând prin faptul că modulul formei gestionate este clar divizat în context. Fiecare procedură (funcție) trebuie să aibă o directivă de compilare. În forma obișnuită, tot codul este utilizat pe Client.

În modulul de formular gestionat, puteți declara proceduri și funcții, puteți declara variabile și descrieți secțiunea programului principal.

Codul de program al programului principal va fi executat la data inițializării formularului, adică. când utilizatorul începe să-l deschidă. Figura prezintă o listă de evenimente standard pentru un formular gestionat.

Lista evenimentelor de formular gestionate este vizibilă și în lista de proprietăți direct pentru formularul în sine. Această listă este apelată în editorul de formulare gestionat.

Într-un formular gestionat, puteți gestiona un eveniment de scriere a articolului. Acest eveniment este prezent doar pentru forme de obiecte (directoare, documente și altele). Dacă formularul nu este atașat la un obiect specific, atunci nu există un eveniment de înregistrare.

Pentru un modul de formulare obișnuit, lista de evenimente standard este ceva mai mică, deoarece într-un formular gestionat, multe evenimente sunt împerecheate (unul este executat pe Client, iar celălalt pe Server). În forma obișnuită, tot codul este executat pe Client.

Modul obiect

Aceste module sunt tipice pentru directoare, documente, planuri de tipuri de decontări, planuri de conturi și multe alte obiecte. Modulul obiect este proiectat pentru a gestiona evenimente standard. De exemplu, un eveniment pentru a introduce un articol de director, un eveniment pentru a înregistra un articol, a șterge, a ține un document etc.

În principiu, un eveniment de înregistrare există și în Modulul formularului. Dar evenimentul de înregistrare din Modulul formularului are loc în procesul de înregistrare interactivă, atunci când lucrează cu un formular specific.

Un eveniment de înregistrare în modulul obiect va fi executat la orice înregistrare de la orice formă a acestui obiect. În plus, dacă obiectul este înregistrat programatic, în acest caz, evenimentul modulului obiect va fi declanșat.

În evenimentul de înregistrare al modulului obiect, puteți încorpora toate verificările pentru corectitudinea datelor înregistrate, deoarece această procedură va funcționa în momentul în care se înregistrează absolut orice înregistrare.

Modulul acestui obiect poate fi apelat prin meniul contextual, din Paleta Proprietății obiectului și din fereastra de editare a obiectelor.

Figura de mai jos prezintă o listă a evenimentelor disponibile ale modulului de director.

În modulul obiect, puteți plasa o secțiune pentru descrierea variabilelor, descrie funcții arbitrare care nu pot fi asociate cu un eveniment, precum și o secțiune a programului principal.

În secțiunea principală a programului, de exemplu, puteți inițializa variabilele locale ale unui modul dat. Acest cod de program va fi executat la accesarea acestui modul obiect.

Trebuie menționat că toate procedurile modulului obiect sunt compilate pe server. În consecință, directivele de compilare pentru procedurile și funcțiile Modulului obiect nu sunt necesare. Unele obiecte de configurare nu au module de obiecte.

Acest lucru se datorează caracteristicilor obiectelor în sine. Astfel de obiecte includ constanteși registre. pentru Constansnu există niciun modul obiect, dar există un modul foarte similar numit Modulul Manager de valoare.

Modulul Manager de valoare   este posibil să procesați înregistrarea evenimentelor constanteși procesarea cecului de umplere.

Întregul context al modulului este executat pe Server.

Pentru registre, există un modul Recordset.

Acest modul are, de asemenea, capacitatea de a procesa înregistrarea evenimentelor și de a efectua o verificare de completare.

În modulele de obiecte, modulele de gestionare a valorii (pentru constante) și modulele de set de înregistrări (pentru registre) puteți descrie metode care pot fi exportate, iar aceste metode vor fi accesibile din exterior.

Ie Pe lângă utilizarea metodelor fixe ale clasei de obiecte, puteți crea metode suplimentare pentru obiect în modulul Obiect. Acest modul trebuie să descrie procedura corespunzătoare cu cuvântul cheie exporturi.

Atunci va fi posibilă accesarea acestei proceduri din exterior. Mai mult, această metodă va fi afișată în contextul de ajutor. Noile metode în contextul de ajutor sunt evidențiate în albastru (pictograma albastră p ()   pentru proceduri și f ()pentru funcții).

În mod similar, puteți crea o proprietate nouă prin declararea unei variabile cu un cuvânt cheie exporturi. Această proprietate poate fi accesată și din exterior.

Astfel, este posibil să se extindă funcționalitatea obiectelor (pentru a defini metode noi și proprietăți noi). Cu toate acestea, proprietățile sunt dinamice și nu sunt stocate în baza de date.

Dacă doriți să utilizați proprietatea care va fi stocată în baza de date pentru obiect, trebuie să creați proprietatea obiectului.

Modul manager

Acest modul există pentru multe obiecte (directoare, documente, registre etc.). Modulul este deschis fie prin meniul contextual pentru obiect, fie prin Paleta de proprietățisau prin fereastra de editare.

În modulul Manager, puteți trece peste unele evenimente standard. De exemplu, în Procesarea primirii datelorcând un element este selectat din director, puteți efectua unele filtrări sau verificări suplimentare.

În plus, în modulul Manager, puteți crea metode suplimentare și indicați că sunt exportate. În acest caz, este posibil să accesați aceste metode din exterior.

Pentru a efectua acest apel, este necesară obținerea unui tip de date SpravochnikMenedzher.

Diferența dintre metodele de export ale modulului Manager și ale modulului obiect este că pentru a accesa metoda modulului obiect, trebuie mai întâi să obțineți obiectul în sine (adică să obțineți cumva o legătură și apoi să convertiți această legătură într-un obiect).

După aceea, variabilele și metodele de export ale modulului obiect vor fi disponibile. Pentru modulul Manager, apelul este mai simplu, de exemplu:
Directoare, contrapartide .Numele metodei

Acestea sunt două căi de atac diferite. Conversia de la link la obiect (metodă) GetObject) - aceasta este o acțiune destul de serioasă pentru sistem, deoarece la primirea unui obiect, se citesc absolut toate datele acestui obiect, care pot fi destul de lungi.

A doua diferență este că Modul obiectnumită în contextul unui element specific. În consecință, putem presupune că este aplicabil pentru acest element (în majoritatea cazurilor, astfel de logici sunt stabilite).

În ceea ce privește modulul Manager, descrie unele acțiuni generale pentru grup sau pentru toate elementele din director sau un document. De exemplu, dacă doriți să imprimați un articol din director, puteți utiliza modulul Obiect.

Dar în modulul Manager este posibil să se realizeze un mecanism mai universal care să imprime, inclusiv un grup de elemente.

În plus, accesarea modulului obiect este încă o acțiune mai lungă. Prin urmare, pentru a rezolva această problemă în modulul manager este mai de preferat.

Aceasta concluzionează cunoștința noastră cu modulele din configurația sistemului 1C: Enterprise. Dacă rezumați rezumatul de mai sus, atunci linia de jos este următoarea concluzie:

• Un modul software este o parte a unei configurații care poate conține text doar în limbajul încorporat 1C
• Modulele software sunt clasificate în funcție de tipurile pe care le-am examinat în acest articol. Fiecare vizualizare este determinată de contextul de plasare și de programul disponibil.
• Structura modulului este formată din unele secțiuni, care sunt dispuse într-o anumită secvență. Compoziția secțiunilor este determinată de tipul modulului.

De asemenea, observăm că am omis în mod deliberat un fel de modul, respectiv modulul de comandă. Nu reprezintă nimic remarcabil și vă sugerăm să vă familiarizați în mod independent cu funcționalitatea acestuia.

Până în prezent, am examinat fragmentar codul programului nostru din soluția aplicată și, de regulă, l-am scris într-o configurație de testare mică. Știi că „nu poți doar să-l iei” și să începi să editezi codul de configurare standard? Nu? Apoi, în articolul următor, vom explica toate acestea!

Adesea, pe parcursul executării programelor, trebuie să obținem valori stocate în baza de date și care nu se schimbă ani de zile. Un exemplu viu este valoarea constantelor. În parte, este posibil să clasificați aici căutarea unui element de director sau a unui nod de plan de schimb după cod, obținând valorile detaliilor obiectelor prin referință.

Fără a gândi, „din mers”, astfel de sarcini sunt rezolvate prin construcții ale formei:

Dacă Document Data\u003e Constante.Start DateApplicationsResults1137.Get () Atunci

Drept urmare, de fiecare dată când este executat acest cod, baza de date „se aruncă”.

Programatorii care sunt mai scrupuloși cu privire la codul lor îndeplinesc o singură întrebare în baza de date, în cache toate datele de care au nevoie, dar această abordare nu duce întotdeauna la descărcarea de bază de date dorită:

1. Ciclul de execuție al codului poate fi implicit (de exemplu, re-documentarea grupului)
2. Obținerea unui set strict de date (nu mai mult și nici mai puțin), care va fi necesar ulterior, este uneori dificil sau chiar imposibil.
3. Valorile din cache trebuie utilizate în apeluri / forme diferite

Modul de reutilizare a valorii de retur

Pentru a rezolva problemele descrise, platforma are module cu valorile de retur din reutilizare. De fapt, acesta este un modul comun obișnuit (client sau server), în care Reutilizarea valorilor de retur este setată pe „La momentul apelului” sau „La ora sesiunii. În modulul în sine, procedurile și funcțiile sunt descrise ca de obicei.

Întreaga idee este că atunci când apelați în mod repetat la funcțiile de export ale unor astfel de module, prima dată apelul este efectiv efectuat așa cum ne așteptăm, iar toate apelurile ulterioare duc la returnarea valorii în cache fără a efectua efectiv codul funcției. Acest efect poate fi observat în măsurarea performanței.

Valorile returnate sunt ascunse în mod natural de valorile parametrilor trecuți, adică. la executarea codului

Node1 \u003d OurModule.GetNode of ExchangeWith Accounting ("0001"); Node2 \u003d OurModule.GetNode of ExchangeWith Accounting ("0002");

Ambele apeluri vor conduce efectiv la executarea procedurii corespunzătoare și la returnarea diferitelor legături, iar în încercările ulterioare de a obține nodul cu codul 0001 sau 0002, nodurile corespunzătoare vor fi returnate fără a apela la procedură și, ca urmare, la baza de date.

Valorile sunt memorate în cache pentru fiecare sesiune pe client sau server (în funcție de modulul client sau server). Ie dacă există caracteristici de setare a drepturilor de acces sau a unei alte dependențe a valorii primite de utilizatorul curent, totul va funcționa corect.

Ce nu se poate face

Există o limitare. Numai tipurile simple pot fi specificate ca parametri ai funcției. Nedefinit, Nul, Boolean, Data, Șir, Număr, Link. Fără structuri, tabele de valori, obiecte etc. Dacă încercați să treceți, de exemplu, o structură ca parametru, totul va funcționa, dar puteți uita să reutilizați valoarea rezultată.

Valoarea de retur poate fi de orice tip.

De asemenea, acordați atenție dimensiunii datelor pe care le introduceți în cache. Este puțin probabil să ucizi toată memoria serverului, dar nu uita că resursele nu sunt interminabile.

Eroare sau caracteristică de la 1C

Valorile reutilizabile au o proprietate interesantă. Această eroare sau caracteristică nu este clară, dar știind despre aceasta nu va strica. Dacă executați următorul cod:

ValueStructure1 \u003d OurModule.GetStructure ofValues \u200b\u200bof Requisites (LinkOnObject); Structura valorii 1. Nume \u003d „Nume nou”; ValueStructure2 \u003d OurModule.GetStructureValues \u200b\u200bof Requisites (LinkOnObject);

Acest lucru în ValueStructure2.Name va conține exact „Nume nou”. În principiu, aceasta poate fi utilizată pentru a actualiza valorile care au fost efectiv schimbate în baza de date, dar atunci când este închisă și dacă banca este închisă, nu este clar. Când se dezvoltă soluții standard, acest lucru este interzis.

Ce trebuie să faceți atunci când schimbați datele din cache

Există o singură metodă „legitimă” pentru a gestiona situația cu modificarea valorii în cache din baza de date. Aceasta este metoda RefreshValues \u200b\u200b(). Valorile tuturor funcțiilor pentru toți parametrii tuturor modulelor vor fi resetate. Actualizarea prin valori / funcții / module ale parametrilor specifici nu este posibilă.

În consecință, datorită unei astfel de abordări voluntariste, este necesară utilizarea acestei funcții cu extremă precauție: după utilizarea acesteia, întregul sistem va funcționa semnificativ mai lent mai mult timp.

Incalcăm sacrul: scriem o cerere în buclă

În plus față de opțiunile evidente pentru utilizarea funcțiilor cu utilizarea repetată a valorilor de retur, există multe abordări interesante, universale, non-standard, inclusiv:

• Redactarea procedurilor universale care returnează detaliile legăturilor arbitrare (disponibile în BSP)
• Proceduri de scriere care returnează valorile constantelor cu numele constantei (există în cele mai tipice)
• Revenind o cantitate de date „puțin mai mare” decât este necesar pentru a reduce numărul de apeluri (de exemplu, dacă doriți să obțineți ratele mai multor valute simultan, este logic să apelați funcția după data fără a selecta o monedă, să obțineți ratele tuturor monedelor și apoi „sortați-o” care monedă este este nevoie de momentul prezent)
• Scrierea unei proceduri care execută o interogare cu memorarea în cache a rezultatului (parametrii de intrare vor fi textul de interogare și câteva nume de valori și valori ale parametrilor)

Dar există o altă abordare pe care vreau să o menționez în detaliu. Aceasta este utilizarea unei funcții care conține un apel DB, cu utilizarea repetată a valorii de retur într-o buclă. Ie aceasta este de fapt o solicitare în buclă. În general, am fost învățați să nu facem acest lucru, dar există momente în care o astfel de construcție a codului va duce la o performanță mai bună dacă:

1. Numărul diferitelor valori ale parametrilor de intrare care apar în ciclu este mic, iar marea majoritate a combinațiilor cu probabilitate ridicată au fost obținute mai devreme în această sesiune.
2. Este dificil să obțineți un set strict de combinații de valori ale parametrilor de intrare într-un ciclu în avans și obținerea de valori pentru toate combinațiile posibile de valori ale parametrilor de intrare va conduce la citirea unei cantități mari de date din baza de date.

După cum puteți vedea, formulările nu sunt corecte și seamănă mai mult cu cuvintele despărțitoare decât cu regulile. Prin urmare, rețineți întotdeauna contextul, evaluați imaginea curentă, luați în considerare condițiile în care va funcționa codul dvs.

Articolul oferă o scurtă privire de ansamblu și caracteristici ale funcționalității cum ar fi Reutilizarea valorilor de retur ale modulelor comune.

Probleme atunci când lucrați cu 1C

Adesea, atunci când se lucrează cu programul 1C, este necesară obținerea valorilor stocate în baza de date, acestea nu se schimbă ani de zile. Un exemplu ar fi valoarea constantelor. La acest grup de valori, se poate clasifica condiționat o căutare a unuia dintre elementele directorului sau o căutare a unui nod de plan de schimb folosind codul, precum și necesitatea obținerii valorii detaliilor proprietății.

Astfel de sarcini sunt rezolvate rapid și simplu folosind construcții de tipul următor:

Dacă Document Data\u003e Constante.Start DateApplicationsResults1137.Get () Atunci

Dar de fiecare dată când este executat acest cod, baza de date este accesată.

Mulți programatori folosesc următoarea metodă pentru a descărca baza de date. Ei îndeplinesc o singură întrebare la KB și memorie cache a datelor de care ar putea avea nevoie. Cu toate acestea, această metodă nu descarcă baza de date la valoarea dorită. Motivele acestui lucru pot fi următoarele:

· Ciclul de execuție a codului nu este clar (de exemplu, în cazul retransmisiei în grup a documentelor);

· Obținerea unui set strict de date care nu este necesar în acest moment este uneori imposibil sau dificil;

· Utilizarea datelor deja memorate în cache în diverse forme / apeluri.

Modul de reutilizare a valorii de retur

Rezolvarea problemelor descrise mai sus va ajuta utilizarea modelelor cu utilizarea repetată a valorilor de retur. Ce este asta Acesta este un modul general de client sau server în care ar trebui să fie setat „Reutilizarea valorilor de retur” în funcțiile „Pentru timpul apelului” sau „Pentru ora sesiunii”. Toate operațiunile și funcțiile direct din modul sunt descrise ca mai înainte.

Avantajul fără îndoială al acestei metode este că returnarea valorii în cache se produce fără executarea reală a codului funcției. Acest lucru se întâmplă cu toate apelurile ulterioare către funcțiile de export ale acestor module. Același efect se poate observa și la măsurarea performanței.

Când codul este executat, valorile returnate sunt memorate în cache prin valorile parametrilor trecuți. Astfel, acest lucru se întâmplă direct în timpul executării codului.

Node1 \u003d OurModule.GetNode of ExchangeWith Accounting ("0001");

   Node2 \u003d OurModule.GetNode of ExchangeWith Accounting ("0002");

Atât un apel, cât și celălalt au ca rezultat operațiunea corespunzătoare și returnează diferite referințe. Cu toate acestea, deja la apelurile următoare, nodurile cu codul 0001 sau 0002 vor reveni fără a provoca oa doua operație și, în consecință, fără a accesa baza de date.

Valorile vor fi memorate în cache în mod izolat în fiecare sesiune atât pe client, cât și pe server (acest lucru depinde dacă apelul a fost făcut de la client sau server). Totul va funcționa perfect în cazul în care există setări pentru drepturile de acces sau orice altă dependență a valorii obținute.

Câteva DAR

Ca în orice regulă, există excepții de la această metodă. Tipurile complexe nu ar trebui specificate în parametrii funcțiilor, ci mai degrabă tipuri simple precum Data, Numărul, Incertitudinea și așa mai departe. Nu încercați să specificați ca parametri, de exemplu, o structură, un obiect sau o tabelă de valori. Veți obține rezultatul pentru prima dată, dar nimic sensibil nu va ieși a doua oară.

Valoarea returnării poate fi de orice tip.

În plus, nu uitați să acordați atenție dimensiunii datelor pe care le căutați, deoarece memoria serverului, deși uriașă, nu este nelimitată.

Caracteristică sau eroare de la 1C

Valorile refolosite au o caracteristică interesantă. Se poate presupune că aceasta este o caracteristică sau un bug, dar în orice caz merită să fiți atenți.

Prin introducerea următorului cod:

ValueStructure1 \u003d OurModule.GetStructure ofValues \u200b\u200bof Requisites (LinkOnObject);
   Structura valorii 1. Nume \u003d „Nume nou”;
   ValueStructure2 \u003d OurModule.GetStructureValues \u200b\u200bof Requisites (LinkOnObject);

în ValueStructure2.Name va apărea exact Noul nume. Aceasta poate fi utilizată pentru a actualiza valorile care au fost efectiv schimbate în baza de date, dar nu se știe cât mai mult timp se poate face acest lucru. Pentru că atunci când se creează soluții standard, acest lucru nu poate fi realizat.

Dacă datele din cache au fost schimbate

Dacă valorile din cache au fost schimbate în baza de date, există o singură modalitate de a o utiliza - metoda RefreshValues. În acest caz, setările tuturor funcțiilor sunt resetate în toate modulele. Nu este posibilă actualizarea prin una dintre valorile parametrilor, fie funcții, fie module.

Cum se face cererea în buclă

Dacă nu doriți să utilizați funcția cu utilizarea repetată a valorilor returnate, vă oferim câteva abordări mai creative pentru a rezolva problema.

· Proceduri universale care returnează detaliile legăturilor arbitrare.

· Crearea de proceduri care returnează valori constante după numele lor. Apropo, astfel de proceduri sunt în versiuni standard.

· Returnarea unui volum ceva mai mare decât suma necesară pentru a reduce numărul de apeluri. De exemplu, dacă trebuie să obțineți cursul de schimb al mai multor monede simultan, este recomandat să apelați funcția exclusiv după dată, fără a selecta valute. După ce ai primit toate cursurile, stabilește ce monedă este acum necesară și care nu.

· Crearea unei proceduri care să execute solicitarea în timp ce se ascunde rezultatul (parametrii de intrare - textul cererii, mai multe nume și valori ale parametrilor).

Aș dori să vorbesc despre o altă metodă mai detaliată. Această metodă se bazează pe utilizarea unei funcții care conține un apel la baza de date, cu utilizarea repetată a valorii de retur direct în buclă, adică un fel de interogare în buclă. În unele cazuri, o astfel de construcție poate îmbunătăți performanța. Trebuie îndeplinită următoarea condiție: trebuie să existe un număr mic de valori diferite ale parametrilor de intrare întâlniți în ciclu, iar majoritatea combinațiilor cel puțin o dată au fost deja obținute mai devreme în această sesiune. Trebuie amintit că este extrem de dificil să obțineți în prealabil un anumit set de combinații ale tuturor valorilor parametrilor de intrare, iar încercările de a obține valori pentru tot felul de combinații pot duce la citirea prea multor date din baza de date.

V-am oferit doar funcții și metode de eșantion. Prin urmare, înainte de a le folosi, evaluați condițiile în care va funcționa codul dvs.