Module generale. Reguli pentru crearea modulelor comune Descrierea modulelor 1c

Aproape toate obiectele de configurare au un modul manager, iar pentru majoritatea obiectelor un modul obiect. Adesea, programatorii începători nu înțeleg diferențele în scopul acestor două module.

Înțelegerea diferenței în scopul lor vă permite să scrieți cod de program mai corect ca structură și, în unele cazuri, să economisiți resursele serverului 1C și să creșteți performanța soluției aplicației.

În acest articol ne vom uita la diferențele fundamentale dintre aceste module, atât din perspectivă teoretică, cât și folosind un exemplu practic specific.

Teorie

Să ne întoarcem la elementele de bază ale programării orientate pe obiecte (OOP) și să facem o analogie cu exemplul nostru. În POO, metodele pentru obiecte pot fi împărțite în static și simplu. Metodele simple pot fi apelate numai pe un obiect specific la care avem acces în contextul de cod curent. Metodele statice nu au acces direct la datele obiectului. Pentru a accesa un obiect, mai întâi trebuie să creați o instanță a acestuia. Același lucru este valabil și pentru platforma 1C:Enterprise 8.x.

În modulul obiect, platforma stochează proceduri și funcții care pot fi apelate numai atunci când se lucrează cu un anumit obiect, de exemplu, cu obiectul elementului de director „Nomenclatură”. Modulul manager conține proceduri și funcții care pot fi aplicate tuturor obiectelor de un anumit tip, dar cu crearea inițială a unei instanțe a acelui obiect. Adică, pentru a schimba un element de nomenclatură din acest modul, mai întâi executați metoda „GetObject()” pentru a face referire la element și apoi lucrați cu el.

Să trecem de la teorie la practică.

Practică

Să trecem la un exemplu practic. Să presupunem că trebuie să rezolvăm problema tipăririi unei liste de produse.Utilizatorul tipărește un produs fie direct dintr-un element de director, fie din formularul de listă de produse. Să luăm în considerare două moduri de a finaliza sarcina.

Procedura de imprimare în modulul obiect

În modulul obiect director, adăugați următoarea funcție:

// Transmite o referință la un element de director la funcție Funcție PrintSelectedProducts(Link) Export TabDoc = New TabularDocument; Layout = directoare. Bunuri. GetLayout ("Aspect"); Solicitare = Solicitare nouă; Cerere. Text = " SELECTAȚI | Produse . Prezentare ca produs,| Bunuri . MarkDeletion,| Bunuri . Cod furnizor |DIN| Director . Produse AS Produse|UNDE | Bunuri . Link B(&Matrice de produse)" ; Solicitare. SetParameter(" Matrice de produse ", Link); //Selectați prin link

Codul programului este complet generat de designerul de imprimare. Singurul lucru demn de remarcat este afișarea prin referire la elementul directorului „Produse” din cerere. Referința este transmisă ca parametru funcției. Ca urmare a apelării funcției „PrintSelectedProducts”, va fi returnat un document de foaie de calcul cu poziția completă a produsului.

Codul programului pentru apelarea metodei obiect „PrintSelectedProducts” folosind comanda formularului „Print” este prezentat în următoarea listă:

&OnClient Procedure Print(Comandă) // Contactați procedura serverului pentru a primi documentul generat de foaia de calcul TabDoc = PrintServer(); // Afișează documentul tabelar generat TabDoc. Spectacol() ; Funcția EndProcedure și OnServer PrintServer() // Convertiți obiectul formular într-un obiect director „Produse” pentru a apela o funcție din modulul obiect ObjectItem = FormAttributeValue("Obiect"); // Apelați procedura modulului obiect, pasând acolo un link către elementul director curent. Rezultat // revenim la partea clientului Returnați ObjectProduct. PrintSelectedProducts(Object.Link) ; EndFunction

Astfel, am tipărit elementul director curent lucrând cu obiectul său. Dar sarcina a spus să tipăriți o listă de produse pe care utilizatorul însuși trebuie să le selecteze. Când lucrați cu un obiect, nu este posibil să oferiți utilizatorului o astfel de oportunitate într-un mod simplu. Cea mai corectă modalitate ar fi să tipăriți din lista de articole din directorul „Produse”.

Procedura de imprimare în modulul manager

Să adăugăm următoarea procedură de export la modulul de manager de directoare:

// Transmite o serie de link-uri către produse Funcția PrintSelectedProducts(ArrayProducts) Export TabDoc = New TabularDocument; Layout = directoare. Bunuri. GetLayout ("Aspect"); Solicitare = Solicitare nouă; Cerere. Text = " SELECTAȚI | Produse . Prezentare ca produs,| Bunuri . MarkDeletion,| Bunuri . Cod furnizor |DIN| Director . Produse AS Produse|UNDE | Bunuri . Link B(&Matrice de produse)" ; Solicitare. SetParameter(" Matrice de produse ", Matrice de produse) ; // Setați selecția după matrice Rezultat = Solicitare. Alerga(); HeaderArea = Aspect. GetArea(„Titlu”); AreaFooter = Aspect. GetArea(" Subsol "); TableHeadArea = Aspect. GetArea("Antet tabel"); TableFooterArea = Aspect. GetArea(„TableFooter”); DetailRecordsArea = Aspect . GetArea(„Detalii”); TabDoc. Clar() ; TabDoc. Ieșire(AreaTitle); TabDoc. Ieșire (TableHeadArea); TabDoc. StartAutoGroupingRows() ; SelectionDetailRecords = Rezultat. Alegeți() ; În timp ce SelectionDetailedRecords. Next() LoopDetailRecordArea. Opțiuni. Fill(SelectionDetailRecords) ; TabDoc. Ieșire(DetailedRecordsArea, DetailedRecordsSelection.Level()) ; EndCycle ; TabDoc. FinishAutoGroupingRows() ; TabDoc. Ieșire (TableFooterArea); TabDoc. Ieșire (AreaFootground) ; Întoarce TabDoc; EndFunction

Principala diferență față de o funcție dintr-un modul obiect este parametrul funcției. Acum, o matrice cu link-uri către produse care trebuie tipărite este trecută ca parametru.

Codul de program al modulului de comandă a formularului „Print” arată astfel:

& Pe Procedura Client Print(Command) TabDoc = PrintServer() ; TabDoc. Spectacol() ; Funcția EndProcedure și OnServer PrintServer() // Treceți o serie de legături ale produselor selectate în lista de directoare // în funcția modulului manager „PrintSelectedProducts” Retur Directoare. Bunuri. PrintSelectedItems(Items.List.SelectedRows) ; EndFunction

În acest caz, rezultatul executării comenzii în modul 1C:Enterprise va fi următorul:

Dacă folosim metoda din modulul manager, putem accesa datele din directorul „Produse” fără a obține un obiect pentru fiecare link. Deoarece obținerea unui obiect înseamnă obținerea tuturor datelor din baza de date pentru un element de director și plasarea datelor primite în RAM, implementarea sarcinii în a doua modalitate va avea un efect pozitiv asupra performanței. La urma urmei, în acest caz vom folosi un minim de resurse (RAM) ale mașinii server.

Ce să folosești?

Ca întotdeauna, totul depinde de sarcina specifică. Dacă trebuie să imprimați un document, atunci cea mai bună opțiune este să utilizați modulul manager. Dacă trebuie să umpleți un obiect, de exemplu, prin prelucrarea externă a pieselor tabulare de umplere, atunci în acest caz este mai bine să plasați proceduri și funcții în modulul obiect, deoarece acestea funcționează în mod specific cu obiectul.

În configurația standard a „Trade Management” versiunea 11, modulul manager este folosit peste tot pentru tipărirea documentelor. Dacă vă uitați la configurația „Managementul întreprinderii de producție”, modulul de manager practic nu este utilizat, deoarece configurația a fost scrisă în versiuni mai vechi ale platformei, unde nu exista suport complet pentru acest mecanism.

Configurare cu exemple din articol.

Articolul continuă seria „Primii pași în dezvoltare pe 1C”, discută în detaliu următoarele probleme:

• Ce este un modul software și din ce secțiuni constă?
• Pentru ce este modulul de aplicație? De ce sunt doi dintre ei? Când începe care? Care sunt subtilitățile lucrării?
• Ce evenimente sunt asociate cu începerea funcționării 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 este utilizat modulul de sesiune?
• Care sunt modulele comune? Care sunt proprietățile și regulile sale de funcționare? De ce să folosiți proprietatea „Reutilizarea valorilor returnate”?
• Când este utilizat modulul formular și ce evenimente pot fi procesate în el?
• Pentru ce este modulul obiect? Din ce secțiuni constă? Cum pot vedea evenimentele disponibile din modul?
• Care sunt subtilitățile lucrului cu modulele de manager de valoare (pentru constante) și modulele de set de înregistrări (pentru registre)?
• Care sunt diferențele dintre un modul obiect și un modul manager? Când ar trebui să-l folosești pe acesta din urmă?

Aplicabilitate

Articolul discută platforma 1C:Enterprise 8.3.4.496. Materialul este, de asemenea, relevant pentru lansările actuale ale platformei.

Modulele din „1C: Enterprise 8.3”

Modulele sunt acele obiecte care conțin cod de program.

Există un număr destul de mare de tipuri de module în Platformă, fiecare dintre ele având propriul scop și caracteristici.

Orice linie de cod trebuie să fie într-un anumit modul. Există module de uz general și module obiect. Unele module pot fi compilate atât pe Client, cât și pe Server, iar unele 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 utilizate ulterior în orice procedură.

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

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

În unele module, variabilele pot avea o locație de compilare (disponibilitate) pe Server sau Client. De exemplu:

Secțiunea care descrie variabile este urmată de o secțiune de proceduri și funcții, unde sunt indicate metodele locale ale acestui modul. Unele module trebuie să specifice unde va fi compilată 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 analizei codului programului, se recomandă să indicați în mod explicit unde va fi compilată o anumită 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, care poate conține unii operatori și poate inițializa variabilele locale ale modulului formular. Această secțiune este executată la accesarea modulului.

Deci, de exemplu, la deschiderea unui formular element, secțiunea principală de program a modulului formular este executată mai întâi.

Trebuie remarcat faptul că secțiunea de declarare a variabilelor și secțiunea principală a programului nu există pentru toate modulele (adică, aceste secțiuni nu sunt valabile în unele module). O secțiune pentru descrierea procedurilor și funcțiilor poate exista în absolut orice modul.

Modul de aplicație

Acest modul este conceput pentru a gestiona evenimentele de pornire și terminare a aplicației. De exemplu, atunci când lansați aplicația, puteți descărca cursurile valutare de pe Internet. Când închideți o aplicație, puteți confirma cu utilizatorul că intenționează să renunțe.

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

Acestea ar putea fi evenimente de la un cititor de carduri magnetice sau un registrator fiscal. Și aceste evenimente pot fi, de asemenea, procesate într-un fel.

Vă rugăm să rețineți că este pornirea interactivă a sistemului care 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 remarcat faptul că în Platforma 8.3 există două module de aplicație diferite: modulul Aplicație gestionată și modulul Aplicație obișnuită. Evenimentele modulului de aplicație gestionată sunt procesate atunci când sunt lansate Clientul subțire și gros al aplicației gestionate și Clientul web.

Modul Aplicare regulată funcționează când rulează Thick Client în modul Aplicare regulată, care conține interfața obișnuită de comandă în formular Meniu principal.

Dacă aplicația rulează A reușit, și în mod Aplicare regulată, atunci este necesar să descriem procedurile de manipulare ca și pentru modul Aplicație gestionată, și pentru modul Aplicare regulată.

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

Acest modul poate fi deschis și din paleta de proprietăți a elementului de configurare rădăcină.

Pentru a deschide un modul Aplicare regulată, ar trebui să vă referiți la setările de configurare (comandă Opțiuniîn meniu Serviciu).

Se va deschide formularul Opțiuni. Pe marcaj Sunt comune trebuie specificat modul de editare a configurației Aplicație gestionatăȘi Aplicare regulată.

În acest caz modulul Aplicare regulată se va putea deschide și din proprietățile nodului rădăcină.

Lista evenimentelor pentru care pot fi procesate A reușitȘi Aplicare regulată e aceeasi.

Acest modul poate conține o secțiune de declarare a variabilelor, o secțiune de descriere a procedurilor și funcțiilor arbitrare și o secțiune principală a programului. Dar, pe lângă procedurile și funcțiile arbitrare, în modul pot fi localizați handlere de evenimente speciale.

Lista manipulanților disponibili poate fi vizualizată apelând lista de proceduri și funcții ale modulului curent atunci când modulul este deschis.

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

Există două evenimente asociate cu pornirea sistemului („înainte” și „la”). Două evenimente asociate cu oprirea sistemului („înainte” și „la”). Și, de asemenea, procesarea evenimentelor externe (de exemplu, evenimente de echipamente comerciale).

Când se execută un handler de evenimente „înainte”, se consideră că acțiunea nu a avut loc încă. Când handlerul de evenimente „la” este executat, acțiunea a fost deja finalizată.

Eveniment Înainte de a porni sistemul apare în momentul lansării Enterprise 8.3, dar aplicația în sine nu a apărut încă pe ecran. Acest eveniment are următorul parametru: Refuz.

Dacă acest parametru ia valoarea Adevărat, atunci aplicația nu va porni. Eveniment La pornirea sistemului presupune că acțiunea a fost deja finalizată, fereastra a fost deja creată și, în acest caz, putem, de exemplu, să afișam un formular special. Nu mai este posibil să refuzi lansarea.

În mod similar, înainte de a închide sistemul, aplicația este încă deschisă și puteți refuza să o închideți. Când sistemul se închide, fereastra aplicației s-a închis deja. Este posibil doar să efectuați acțiuni suplimentare, de exemplu, ștergerea unor fișiere sau trimiterea unui e-mail.

În modul Aplicație gestionată Directivele pentru compilarea procedurilor și funcțiilor nu sunt specificate, deoarece modulul este compilat în întregime pe partea Clientului. 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, apoi pentru aceasta va trebui să creați un apel special cu un steag .

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

Procedurile, funcțiile și variabilele unui modul de aplicație pot fi descrise ca exporturi.

Deoarece modulul este compilat în întregime pe Client, aceasta înseamnă că în procedurile client putem accesa această metodă și această proprietate.

De exemplu, puteți apela o procedură sau o funcție a unui modul de aplicație din modulul de formular al unui obiect. Cu toate acestea, se recomandă utilizarea modulelor comune pentru a descrie algoritmi generali. Scopul principal al modulului de aplicație este de a procesa punctul de început și punctul final.

Prin analogie cu un modul de aplicație, acest modul este conceput pentru a procesa evenimentul de deschidere a programului și evenimentul de închidere.

Spre deosebire de modulul de aplicație, care este inițiat în momentul lansării interactive a aplicației, modulul de conectare extern funcționează în modul de conectare COM, adică. când un obiect 1C:Enterprise 8 este creat și conectat la o anumită bază de date.

Acest modul are evenimente: La pornirea sistemuluiȘi La oprirea sistemului.

Modulul de conexiune externă poate fi deschis utilizând fie meniul contextual la nivel de obiect de configurare rădăcină, fie paleta de proprietăți pentru nodul rădăcină.

Procesul de conectare externă în sine este un proces de lucru programatic cu baza de informații, și nu interactiv. În consecință, în acest moment nu puteți utiliza formulare de dialog sau afișa mesaje de avertizare, deoarece nu există interfață cu utilizatorul.

În Modulul de conexiune externă este posibil să se descrie variabilele de export și metodele de export care vor fi disponibile pe partea în care are loc apelul extern la 1C:Enterprise 8.3.

Deoarece nu există o interfață cu utilizatorul într-o îmbinare exterioară, Modulul de îmbinare externă este compilat în întregime pe server.

Modul de sesiune

Acest modul este necesar pentru a inițializa parametrii sesiunii. Parametrii de sesiune 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 a nodului rădăcină.

Modulul de sesiune oferă un eveniment SettingSessionParameters.

Când pornește aplicația, această procedură este apelată mai întâi. Parametrii de sesiune sunt necesari pentru orice operațiune a aplicației: atât când este lansată interactiv, cât și când este lansată în modul de conectare externă.

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

Acest modul, de regulă, descrie mai multe proceduri care sunt apelate din procedură SettingSessionParameters. Prin urmare, toate aceste proceduri sunt separate într-un modul separat.

Modulul de sesiune rulează întotdeauna în modul privilegiat. Aceasta înseamnă că nu va fi efectuată nicio verificare a permisiunilor la accesarea bazei de date. Modulul de sesiune este compilat pe Server, adică Este posibil să accesați orice metodă de server (inclusiv citirea valorilor din baza de date).

În Modulul de Sesiune este posibil să se definească numai proceduri și funcții, de ex. nu există o secțiune de descriere variabilă și nici o secțiune principală a programului. Nu puteți defini metode de export într-un Modul de sesiune.

Dacă, la pornirea sistemului, este necesară efectuarea unor acțiuni pe Server, de exemplu, crearea unui element dintr-un director, atunci, opțional, este posibil să se utilizeze Modulul de sesiune, deoarece este compilat pe server și este întotdeauna executat în mod fiabil la pornirea sistemului. Cu toate acestea, trebuie luate în considerare următoarele puncte:

• procedură SettingSessionParameters se execută nu numai la pornirea sistemului, ci și la accesarea parametrilor de sesiune neinițializați. Acestea. handlerul SetSessionParameters poate fi apelat în mod repetat în timpul funcționării aplicației;
• dacă numărul de elemente din matricea parametrilor de sesiune este zero (matricea parametrilor necesari are un tip de date Undefined), atunci acesta este momentul lansării aplicației;
• întrucât Modulul de sesiune funcționează în modul privilegiat și nu va exista nicio verificare a drepturilor de acces, ar trebui să lucrați cu mare atenție cu obiectele bazei de date, deoarece utilizatorul poate obține acces la date care nu ar trebui să îi fie furnizate;
• Când sistemul pornește, nu se știe încă sigur dacă aplicația va fi lansată. În acest caz, acțiunile inutile pot fi efectuate în handlerul de evenimente SetSessionParameters.

Aceste module reprezintă o descriere a unor algoritmi generali, de ex. proceduri și funcții care pot fi apelate din diverse locuri.

Metodele legate logic pot fi grupate în diferite module comune. Aceste module sunt create în interiorul ramurii General.

Puteți adăuga orice număr de module partajate. Pentru ca metodele Common Module să fie disponibile în altă parte a configurației, acestea trebuie definite cu cuvântul cheie Export. Procedurile client ale modulelor comune vor fi disponibile pe Client, iar cele server – pe Server.

În Modulele generale, este disponibilă doar secțiunea care descrie proceduri și funcții. Acestea. în Modulul General nu puteți descrie variabile și nu puteți descrie o secțiune a programului principal.

Dacă este necesară o variabilă globală, puteți utiliza fie parametrii de sesiune, fie variabilele de export ale modulelor de aplicație.

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

Acestea. cel Modul general va participa la formarea contextului de configurare globală.

Proprietate Global pentru modulele generale poate fi util. Cu toate acestea, nu ar trebui să-l utilizați peste tot pentru toate modulele comune.

Acestea , care sunt marcate cu semnul Global, va fi compilat la pornirea sistemului. Cu cât mai multe astfel de module, cu atât programul va porni mai lent.

Dacă steagul Global Pentru Modul general nu este specificat, atunci compilarea acestui modul va fi efectuată în momentul primului apel către acesta (adică după pornirea sistemului).

În plus, utilizarea modulelor comune globale afectează înțelegerea codului. Metodele unui modul comun non-global sunt numite prin nume Modul generalși numele metodei, de exemplu:
Modul de calcul al costurilor.DistributeIndirectCosts();

În acest caz, denumirile modulelor comune trebuie să reflecte conținutul procedurilor descrise în acestea. Specificarea numelui modulului comun la apelarea unei proceduri ajută la înțelegerea mai bună a codului.

Pentru Modul general V Paleta de proprietăți puteți seta proprietatea Privilegiat.

Modulul privilegiat nu controlează drepturile de acces. Acest lucru este necesar dacă Modul general Este necesară efectuarea prelucrării în masă a datelor, obținând date din baza de date.

Controlul drepturilor de acces crește timpul necesar pentru a accesa o bază de date, iar algoritmii de masă trebuie adesea să funcționeze cât mai repede posibil.

De exemplu, salarizarea este o operațiune care necesită mult resurse. Trebuie făcută cât mai repede posibil. Pentru a face acest lucru, algoritmii care calculează salariile sunt plasați în privilegii .

Totodată, toate procedurile care asigură completarea documentelor de salarizare sunt în afara acestora Module comune. În aceste proceduri se realizează controlul drepturilor de acces.

În acest fel, se pot obține îmbunătățiri semnificative ale performanței. Acest lucru este valabil mai ales atunci când se utilizează un mecanism pentru controlul accesului rând cu rând la înregistrările de tabel.

Dacă un Modul Comun este privilegiat, atunci procedurile acestui modul pot fi compilate numai pe Server.

Există situații în care un obiect ar trebui să fie inaccesibil utilizatorului, de exemplu, un anumit director. Dar atunci când se realizează orice document, este necesară referirea la această carte de referință.

Acestea. Este necesar să extindeți temporar drepturile de utilizator și apoi să le readuceți la starea inițială. Acest efect poate fi obținut utilizând privilegiul Module comune.

Pentru a face acest lucru într-un privilegiat Modul general Ar trebui să creați o procedură care să acceseze datele necesare.

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

Pentru Module comune Este posibil să specificați locația de compilare. Indicatoarele sunt folosite pentru a determina dacă Modulul Comun va fi disponibil pe Client (aplicație gestionată), pe Server sau în modul Conexiune externă.

În plus, dacă comutați modul de editare a configurației la Aplicație gestionată și aplicație obișnuită, atunci 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 care rulează, în funcție de lucrul pe Client sau pe Server, anumite Module Comune vor fi disponibile sau indisponibile.

În plus față de capacitatea de a specifica steaguri de compilare, este posibil să specificați directive de compilare pentru proceduri și funcții situate în Modulul Comun.

Dacă pentru o metodă este specificată o directivă de compilare, atunci, deși Modulul Comun este disponibil în toate contextele specificate, disponibilitatea metodei specifice va fi limitată de directiva de compilare.

În acest caz, procedura nu poate fi accesată într-un context care nu este accesibil întregului modul.

Dacă nu specificați o directivă de compilare pentru o procedură (funcție), aceasta va fi compilată în toate contextele definite pentru modul.

Acestea. În esență, se vor face mai multe copii ale procedurii. Alegerea unei anumite instanțe compilate depinde de locul în care este apelată procedura (după regula de apelare cea mai apropiată). Trebuie avut în vedere faptul că codul unei astfel de proceduri trebuie scris ținând cont de disponibilitatea acesteia în toate contextele definite pentru modul.

Modulele generice care sunt accesibile simultan în mai multe contexte diferite sunt concepute în primul rând pentru a crea proceduri care sunt accesibile în mai multe contexte.

Când se creează un Modul General, se consideră o bună practică să nu se specifice directivele de compilare. Acestea. Disponibilitatea procedurilor și funcțiilor ar trebui să fie determinată de proprietățile modulului însuși.

Cu această abordare, procedurile client vor fi localizate în module comune separate, iar procedurile server vor fi localizate în module comune separate.

Modulele care au setate mai multe steaguri de compilare sunt folosite extrem de rar în practică. Acestea sunt câteva acțiuni comune disponibile atât pe client, cât și pe server. De obicei, acestea sunt niște calcule simple.

Important! Este posibil ca Clientul să acceseze metodele serverului de export ale unui Modul Comun, dar numai dacă acest Modul Comun este compilat numai pe Server. În acest caz, este furnizat un steag special pentru a oferi acces de la Client .

Pentru modulele comune non-globale, este posibil să stocați în cache valorile returnate de funcții. Acestea. După primul apel al unei funcții, sistemul își poate aminti rezultatul execuției acesteia. Dacă această funcție este apelată din nou cu aceiași parametri, sistemul va returna valoarea din cache.

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

În mod implicit, această proprietate este setată la Nu folosiți. Alte valori posibile: cache În timpul apelului, sau Pe durata sesiunii.

Această proprietate are sens să fie utilizată numai pentru acele funcții ale căror rezultate depind numai de parametrii de intrare. Acest mecanism este disponibil numai pentru modulele comune non-globale.

Dacă este selectată valoarea parametrului corespunzător Pentru durata apelului, memoria cache va funcționa atâta timp cât rulează procedura din care a fost apelată metoda Modulului General. Dacă este selectată valoarea Pentru durata sesiunii, atunci se presupune în mod condiționat că memoria cache va funcționa în timp ce utilizatorul lucrează.

Cu toate acestea, există anumite restricții de timp. Cache-ul este șters automat la 20 de minute după ce valoarea intră în cache.

Modul formular

Acest modul este conceput pentru a procesa acțiunile utilizatorului. De exemplu, descrieți algoritmul pentru modul în care un program reacționează atunci când este apăsat un buton. Sau, de exemplu, în momentul introducerii unei valori într-un câmp, verificați imediat corectitudinea.

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

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

Există forme controlate și forme regulate. Modulele acestor formulare diferă în primul rând prin faptul că modulul de formular gestionat este clar împărțit în context. Fiecare procedură (funcție) trebuie să aibă o directivă de compilare. În formă normală, tot codul este utilizat pe Client.

Într-un modul de formular gestionat, puteți declara proceduri și funcții, puteți declara variabile și puteți descrie o secțiune a programului principal.

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

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

Într-o formă gestionată, puteți gestiona evenimentul de scriere a articolului. Acest eveniment este prezent doar pentru formele obiect (directoare, documente și altele). Dacă formularul nu este legat de un anumit obiect, atunci nu există niciun eveniment de scriere.

Pentru un modul de formă obișnuită, lista evenimentelor standard este oarecum mai mică, deoarece Într-o formă gestionată, multe evenimente sunt făcute pentru a fi împerecheate (unul este executat pe Client și celălalt pe Server). În forma sa normală, tot codul este executat pe Client.

Modul obiect

Aceste module sunt tipice pentru directoare, documente, planuri pentru tipuri de calcule, planuri de conturi și multe alte obiecte. Modulul obiect este conceput pentru a gestiona evenimente standard. De exemplu, un eveniment pentru introducerea unui element de director, un eveniment pentru scrierea unui element, ștergerea, postarea unui document etc.

În principiu, evenimentul de scriere există și în Modulul Formular. Dar evenimentul de scriere din Modulul Formular are loc în timpul procesului de înregistrare interactivă, atunci când se lucrează cu un anumit formular.

Evenimentul de scriere din modulul obiect va fi executat pe orice scriere din orice formă a obiectului dat. În plus, dacă obiectul este scris programatic, evenimentul modulului obiectului se va declanșa.

În cazul de scriere a modulului obiect, puteți include toate verificările pentru corectitudinea datelor care sunt scrise, deoarece această procedură va fi executată în momentul absolut oricărei înregistrări.

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

Figura de mai jos arată o listă de evenimente disponibile pentru modulul de director.

În Modulul Obiect puteți plasa o secțiune pentru descrierea variabilelor, descriind funcții arbitrare care ar putea să nu fie asociate cu un eveniment, precum și o secțiune a programului principal.

În secțiunea principală a programului, puteți, de exemplu, să inițializați variabilele locale ale unui anumit modul. Acest cod de program va fi executat atunci când acest obiect Modul este accesat.

Trebuie remarcat faptul 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 obiect.

Acest lucru se datorează caracteristicilor obiectelor în sine. Astfel de obiecte includ constanteȘi Registrele. Pentru Constant nu există un modul obiect, dar există un modul foarte asemănător numit Modulul de management al valorii.

ÎN Modulul de management al valorii vă puteți ocupa de evenimente de scriere constanteși procesarea de verificare a umplerii.

Întregul context al modulului este executat pe Server.

Pentru registre există un Modul Recordset.

Acest modul are, de asemenea, capacitatea de a gestiona evenimente de scriere și de a efectua verificări de ocupare.

În modulele obiect, modulele Value Manager (pentru constante) și modulele Recordset (pentru registre) puteți descrie metode care pot fi făcute exportabile, iar aceste metode vor fi accesibile din exterior.

Acestea. Pe lângă utilizarea metodelor fixe ale unei clase de obiecte, puteți crea metode suplimentare pentru un obiect în Modulul Obiect. Acest modul ar trebui să descrie procedura corespunzătoare cu cuvântul cheie Export.

Atunci se va putea accesa această procedură din exterior. Mai mult decât atât, această metodă va fi afișată în context tooltip. Noile metode din panoul explicativ context sunt evidențiate cu font albastru (pictograma albastră p() pentru proceduri și f() pentru funcții).

În mod similar, puteți crea o proprietate nouă declarând o variabilă cu cuvântul cheie Export. Această proprietate poate fi accesată și din exterior.

În acest fel, este posibilă extinderea funcționalității obiectelor (pentru a defini noi metode și noi proprietăți). Cu toate acestea, proprietățile sunt dinamice și nu sunt salvate în baza de date.

Dacă trebuie să utilizați o proprietate pentru un obiect care va fi stocat în baza de date, ar trebui să creați un atribut de obiect.

Modul manager

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

În Modulul Manager puteți suprascrie unele evenimente standard. De exemplu, în ProcesareReceivingSelectionData, atunci când un element este selectat din director, se pot face o filtrare sau verificare suplimentară.

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

Pentru a efectua acest apel este necesar să obțineți tipul de date DirectoryManager.

Diferența dintre metodele de export ale Modulului Manager și Modulul 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ă aceasta, vor fi disponibile variabilele și metodele de export ale Modulului Obiect. Pentru Modulul Manager apelul este mai simplu, de exemplu:
Directoare.Contrapartide.NumeMetodă

Acestea sunt două apeluri diferite. Convertiți de la referință la obiect (metoda GetObject) este o acțiune destul de serioasă pentru sistem, deoarece la primirea unui obiect sunt citite absolut toate datele acestui obiect, ceea ce poate fi destul de lung.

A doua diferență este că Modul obiect numită în contextul unui element specific. În consecință, putem presupune că este aplicabil pentru un element dat (în cele mai multe cazuri, aceasta este exact logica folosită).

În ceea ce privește Modulul Manager, acesta descrie o acțiune comună pentru un grup sau pentru toate elementele unui director sau a unui document. De exemplu, dacă trebuie să imprimați un element de director, puteți utiliza Modulul Obiect.

Dar în Modulul Manager este posibil să se creeze un mecanism mai universal care va imprima, printre altele, un grup de elemente.

În plus, accesarea obiectului Modul este încă o acțiune mai lungă. Prin urmare, este mai de preferat să rezolvați această problemă în modulul manager.

Aceasta încheie cunoștințele noastre cu modulele din configurația sistemului 1C:Enterprise. Dacă rezumăm pe scurt toate cele de mai sus, concluziile de bază sunt următoarele:

• Un modul software este o parte a configurației care poate conține doar text în limbajul 1C încorporat
• Modulele software sunt clasificate în funcție de tipurile pe care le-am discutat în acest articol. Fiecare vizualizare este determinată de plasarea sa și de contextul programului disponibil.
• Structura modulului constă din mai multe secțiuni, care sunt aranjate într-o anumită secvență. Compoziția secțiunilor este determinată de tipul de modul.

De asemenea, rețineți că am omis în mod deliberat un tip de modul, și anume modulul de comandă. Nu este nimic remarcabil și vă invităm să vă familiarizați cu funcționalitatea acestuia.

Până acum, am luat în considerare tot codul programului nostru separat de soluția aplicației și, de regulă, l-am scris într-o configurație mică de testare proprie. Știți că „nu puteți pur și simplu să mergeți” și să începeți editarea codului unei configurații standard? Nu? Apoi, în următorul articol vă vom explica totul!

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

Cum se utilizează modulul partajat

Este o bună practică 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 corectată, 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 înregistrării într-un registru, obținerea sumei diferenței în zile lucrătoare, recalcularea cursurilor de schimb, recalcularea cantității/prețului/suma în secțiunea tabelar și alte funcții.

Proprietățile modulelor comune

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

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

Să aruncăm o privire mai atentă la paleta de proprietăți a modulului general:

• Global- dacă flag-ul este setat, funcțiile și procedurile din acest modul devin disponibile în context global. Acestea. acestea pot fi apelate oriunde în configurație prin accesare fără numele modulului comun. Cu toate acestea, se adaugă o condiție - numele procedurilor și funcțiilor din acest modul comun trebuie să fie unice în contextul global.
• Server— procedurile și funcțiile acestui modul comun pot fi executate pe server.
• Îmbinare exterioară— codurile de program ale acestui modul comun pot fi executate atunci când sunt conectate printr-o sursă externă (de exemplu, COM).
• Client (aplicație gestionată)— procedurile și funcțiile acestui modul comun pot fi utilizate într-un client gros în modul aplicație gestionată.
• Client (aplicație obișnuită)— codurile de program ale acestui modul comun pot fi utilizate într-un client gros în modul de aplicație normal.
• Apel pe server— un flag care permite clientului să utilizeze proceduri și funcții din acest modul comun.
• - dacă este setată la True, verificarea drepturilor de acces va fi dezactivată în acest modul comun.
• Reutilizați— definește setările valorilor returnate; dacă opțiunea este activată, atunci după prima execuție sistemul își va aminti valoarea pentru acești parametri de intrare și va returna o valoare gata făcută. Poate lua următoarele valori: nefolosit- închide, pe durata apelului- pe durata unei anumite proceduri, pe durata sesiunii— până când utilizatorul închide sesiunea (programul).

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

Modul de aplicație gestionată

Conceput în principal pentru a surprinde momentul pornește aplicația și momentul în care se închide. Există și handler-uri aici care vă permit să interceptați un eveniment extern din echipament. În modulul de aplicație gestionată, este monitorizată pornirea interactivă a sistemului.

Evenimentele modulului de aplicație gestionată se declanșează atunci când sunt lansate clientul subțire, clientul web și clientul gros al aplicației gestionate. În modulul de control aplicațiile pot fi accesate din paleta de proprietăți a nodului de configurare rădăcină sau din meniul contextual numit pe nodul de configurare rădăcină.

Modul de aplicare obișnuit

Modulul de aplicație obișnuit joacă același rol ca și modulul de aplicație gestionată, doar evenimentele modulului de aplicație obișnuit sunt declanșate atunci când este lansat clientul gros al aplicației obișnuite.

Modulul obișnuit al aplicației va deveni disponibil din paleta de proprietăți a nodului de configurare rădăcină după setarea opțiunii „Editare configurație pentru modurile de lansare” din parametrii configuratorului din fila „General” la „Aplicație gestionată și normală”.

Modul de conectare extern

Modulul de conectare extern este proiectat pentru a gestiona evenimentul de conectare (nu interactiv, dar în modul de conectare COM) și deconectare. Există manipulatori corespunzători. Cu o conexiune COM, o fereastră interactivă nu se deschide, așa că funcțiile de dialog cu utilizatorul nu vor funcționa. Este posibil să descrieți variabilele și metodele de export în modul. Modulul de conectare extern este compilat pe server. Acestea. este posibil să accesați obiectele de configurare corespunzătoare, de exemplu, directoare.

Modul de sesiune

Există un astfel de obiect de configurare general ca „Parametrii sesiunii”. Modulul de sesiune este creat pentru a inițializa parametrii de sesiune (există un eveniment specific pentru aceasta; când pornește aplicația, pornește prima).

Se rulează în modul privilegiat (drepturile de acces nu sunt verificate la accesarea bazei de date). Modulul de sesiune este compilat pe server. Nu există o secțiune pentru descrierea variabilelor și o secțiune pentru programul principal; metodele de export nu pot fi descrise; este folosit doar pentru setarea parametrilor de sesiune. După cum puteți vedea, modulul de sesiune are un scop foarte restrâns.

Module comune

Modulele comune descriu niște algoritmi obișnuiți și conțin funcții care pot fi apelate din diferite locuri. Modulele comune pot fi compilate atât pe client, cât și pe server.

În modulele generale, este disponibilă NUMAI secțiunea care descrie proceduri și funcții. Dacă trebuie să utilizați o variabilă globală, puteți utiliza fie parametrii de sesiune, fie o variabilă de export a unui modul de aplicație gestionat.

În modulul general, puteți seta câțiva parametri care îi vor afecta comportamentul. Dacă caseta de selectare „Global” este bifată în modulul general, atunci funcțiile sale de export vor participa la formarea contextului global. Și pot fi accesate direct din alt context (fără a menționa numele modulului comun): CommonModuleMethod();

Nu ar trebui să utilizați proprietatea „Global” a modulelor comune peste tot, deoarece astfel de module sunt compilate la pornirea sistemului și încetinesc pornirea programului

Modul obiect

Multe obiecte de configurare (directoare, documente etc.) au un modul obiect. Puteți introduce evenimente standard în el, cum ar fi crearea unui nou articol de director, înregistrarea unui nou obiect, ștergerea, procesarea înregistrării unui document etc. Evenimentul de înregistrare există atât în ​​modulul formular (apare în timpul procesului de înregistrare interactiv când utilizatorul face clic pe butonul „înregistrare”), cât și în modulul obiect.

Trebuie amintit că un obiect poate avea mai multe forme. Prin urmare, evenimentul de înregistrare trebuie procesat în modulul obiect. Aici este verificată corectitudinea datelor înregistrate.

Un modul de obiect poate fi apelat din paleta de proprietăți a unui obiect dat sau din meniul contextual. Structura unui modul obiect nu este diferită de un modul formular. Modulul obiect este compilat pe server, deci nu sunt necesare directive de compilare.

Modul formular

Modulul formular este proiectat pentru a gestiona acțiunile utilizatorului (tratarea unui eveniment de clic pe buton etc.). Există, de asemenea, evenimente asociate direct cu formularul în sine (de exemplu, evenimentul deschiderii, închiderii acesteia). Modulele de formular gestionate și cele obișnuite diferă în primul rând prin faptul că modulul de formular gestionat este clar separat în context. Fiecare procedură trebuie să aibă o directivă de compilare. În formă normală, tot codul este executat pe client.

Structura unui formular gestionat conține o secțiune pentru descrierea variabilelor, o secțiune pentru proceduri și funcții și o secțiune pentru programul principal (executat în momentul inițializării formularului). Putem accesa evenimentele de formular standard prin lista de proceduri și funcții (Ctrl+Alt+P) sau în paleta de proprietăți a formularului propriu-zis. De asemenea, puteți procesa evenimentul de înregistrare a elementului într-o formă gestionată (acest eveniment este prezent doar pentru obiecte: directoare, documente).

Modulul de gestionare a obiectelor

Modulul manager a apărut doar în 1C 8.2; există în multe obiecte de configurare. Scopul principal al modulului de gestionare a obiectelor este de a suprascrie evenimentul standard „Procesarea datelor de selecție de primire”, iar în el putem, de asemenea,

Modulul de management al valorii

Obiectul de configurare constantă nu are un modul obiect, dar există un modul foarte asemănător - modulul de gestionare a valorii. În modulul de gestionare a valorii constante, puteți descrie diverse proceduri (inclusiv cele de export), precum și procesați 3 evenimente: BeforeWrite, OnWrite, ProcessingFillCheck. Acest modul este compilat pe server.

Module recordset

Modulul recordset este analog cu modulul obiect și este inerent în registre. Există evenimente standard în modulul set de înregistrări:

• Înainte de înregistrare
• La înregistrare
• Se procesează verificarea umpluturii

În modulul recordset există o secțiune pentru descrierile variabilelor, procedurilor și funcțiilor (inclusiv cele de export), o secțiune pentru programul principal.

1.1. Modulele comune sunt create pentru a implementa proceduri și funcții unite în funcție de anumite caracteristici. De regulă, procedurile și funcțiile unui subsistem de configurare (vânzări, achiziții) sau procedurile și funcțiile cu funcționalitate similară (lucrarea cu șiruri, scop general) sunt plasate într-un singur modul comun.

1.2. Când dezvoltați module partajate, ar trebui să alegeți unul dintre cele patru contexte de execuție a codului:

	Tip de modul comun	Exemplu de nume	Apel pe server	Server	Îmbinare exterioară	Client (aplicație regulată)	Client (aplicație gestionată)
1.	Server	Uz general (sau Server de uz general)
2.	Server pentru a apela de la client	General PurposeCallServer
3.	Client	Client cu scop general (sau cu scop general global)
4.	Client server	General PurposeClientServer

2.1. Module comune ale serverului sunt destinate să găzduiască proceduri și funcții de server care nu sunt disponibile pentru utilizare din codul client. Ei implementează toată logica de afaceri a serverului intern a aplicației.
Pentru funcționarea corectă a configurației în conexiune externă, modurile de aplicare gestionate și regulate, procedurile și funcțiile serverului trebuie plasate în module comune cu următoarele caracteristici:

• Server(Caseta de bifat Apel pe server resetare),
• Client (aplicație obișnuită),
• Îmbinare exterioară.

În acest caz, capacitatea de a apela procedurile și funcțiile serverului cu parametri de tipuri modificabile (de exemplu, DirectoryObject, DocumentObjectși așa mai departe.). De obicei, acesta este:

• handlere pentru abonamente la evenimente de documente, directoare etc., care iau ca parametru o valoare mutabilă (obiect).
• proceduri și funcții de server, la care un obiect este trecut ca parametru din module de directoare, documente etc., precum și din module cu abonamente la evenimente.

Modulele partajate pe partea serverului sunt denumite conform regulilor generale pentru denumirea obiectelor de metadate.
De exemplu: Lucrul cu fișierele, Scop general

În unele cazuri, un postfix poate fi adăugat pentru a preveni conflictele de nume cu proprietățile contextului global "Server".
De exemplu: RoutineTasksServer, Server de schimb de date.

2.2. Module comune de server pentru apelarea de la client conțin proceduri și funcții de server care pot fi utilizate din codul client. Ele constituie interfața de programare client a serverului de aplicații.
Astfel de proceduri și funcții sunt plasate în module comune cu următoarea caracteristică:

• Server(Caseta de bifat Apel pe server instalat)

Modulele comune de pe partea de server pentru apelarea de la un client sunt denumite conform regulilor generale pentru denumirea obiectelor de metadate și trebuie denumite cu un postfix "CallServer".
De exemplu: Lucrul cu FilesCalling Server

Vă rugăm să rețineți că procedurile și funcțiile de export din astfel de module partajate nu trebuie să conțină parametri de tipuri modificabile ( DirectoryObject, DocumentObject etc.), deoarece transferul lor de la (sau către) codul client este imposibil.

Vezi si:Restricții privind setarea steagului „Apel server” pentru modulele comune

2.3. Module comune pentru client conţin logica de afaceri a clientului (funcţionalitate definită numai pentru client) şi au următoarele caracteristici:

• Client (aplicație gestionată))
• Client (aplicație obișnuită)

Excepția este atunci când procedurile și funcțiile client trebuie să fie disponibile numai în modul aplicație gestionată (doar în modul aplicație obișnuită sau numai în modul conexiune externă). În astfel de cazuri, o altă combinație a acestor două caracteristici este acceptabilă.

Modulele comune ale clientului sunt denumite cu un postfix "Client".
De exemplu: Lucrul cu FilesClient, General PurposeClient

Vezi și: minimizarea codului care rulează pe client

2.4. În unele cazuri, este permisă crearea de module comune client-server cu proceduri și funcții, al căror conținut este același atât pe server, cât și pe client. Astfel de proceduri și funcții sunt plasate în module comune cu următoarele caracteristici:

• Client (aplicație gestionată)
• Server(Caseta de bifat Apel pe server resetare)
• Client (aplicație obișnuită)
• Îmbinare exterioară

Modulele comune de acest tip sunt denumite cu postfix "Client server".
De exemplu: Lucrul cu FilesClient, General PurposeClientServer

În general, nu se recomandă definirea unor module comune atât pentru server, cât și pentru client (aplicație gestionată). Se recomandă implementarea funcționalității definite pentru client și pentru server în diferite module comune - vezi paragrafele. 2.1 și 2.3. Această separare explicită a logicii de afaceri client și server este dictată de considerentele de creștere a modularității soluției aplicației, simplificarea controlului dezvoltatorului asupra interacțiunii client-server și reducerea riscului de erori din cauza diferențelor fundamentale în cerințele de dezvoltare a clientului și serverului. cod (necesitatea de a minimiza codul executat pe client, disponibilitatea diferită a obiectelor și a tipurilor de platforme etc.). În acest caz, trebuie să aveți în vedere creșterea inevitabilă a numărului de module comune în configurație.

Un caz special de module mixte client-server sunt modulele de formă și comandă, care sunt special concepute pentru a implementa logica de afaceri server și client într-un singur modul.

3.1. Se recomandă ca numele modulelor comune să respecte regulile generale pentru denumirea obiectelor de metadate. Numele modulului general trebuie să se potrivească cu numele subsistemului sau mecanismului separat, ale căror proceduri și funcții le implementează. Se recomandă evitarea unor astfel de cuvinte generale precum „Proceduri”, „Funcții”, „Handlers”, „Modul”, „Funcționalitate”, etc. în denumirile modulelor comune. și folosiți-le numai în cazuri excepționale când dezvăluie mai pe deplin scopul modulului.

Pentru a face distincția între modulele comune ale unui subsistem, care sunt create pentru a implementa proceduri și funcții efectuate în contexte diferite, se recomandă să le acordați postfixele descrise mai devreme în paragrafe. 2.1-2.4.