Descrierea formelor controlate uv 1s. StavAnalit

Știm cu toții că compania 1C a avut multe versiuni diferite ale platformei 1C, acum vom fi interesați de una dintre cele mai recente versiuni la momentul scrierii acestui articol, acestea sunt versiunile 1C 8.2 și 1C 8.3. Dacă ați trebuit să lucrați în ambele versiuni, atunci cel mai probabil a observat diferențe în interfețele acestor versiuni, pentru utilizatori diferă doar ca aspect. În esență, o alegere aplicație obișnuită sau gestionată spune sistemului ce formulare să afișeze să ruleze, regulat sau controlat, precum și ce client de aplicație va fi utilizat implicit, gros sau subțire. Pentru informații mai detaliate despre clienți, citiți articolul „Ce sunt clienții grosi și subțiri în 1C, precum și diferențele lor.”

Aplicație obișnuită 1C (forme obișnuite, interfață obișnuită, versiunea 1C 8.2)

În 1C 8.2 este posibil să funcționeze numai cu forme obișnuite, în modul obișnuit de aplicare. Imaginea de mai jos prezintă baza de date în modul de operare „aplicație obișnuită 1C” (formulare obișnuite).

Aplicație gestionată 1C (formulare gestionate, interfață gestionată, versiunea 1C 8.3)

Pe platforma 1C 8.3 putem lucra atât cu forme obișnuite (în modul de compatibilitate), cât și cu cele gestionate. în plus formularele gestionate au două tipuri de afișare, acesta este standard și taxi. Un exemplu de configurație 1C 8.3 cu formulare standard gestionate este prezentat mai jos, iar după aceasta este afișată interfața „Taxi”.

Care este diferența dintre o aplicație 1C obișnuită și gestionată?

După cum am aflat deja o aplicație obișnuită și o aplicație gestionată sunt aceste tipuri de lansare a unui program 1C. Mai mult, în funcție de valoarea tipului de lansare 1C ( aplicație obișnuită sau gestionată), o interfață specifică va fi încărcată implicit ( forme regulate sau gestionate), prin urmare, există atât de multe sinonime pentru acest concept. Dorim să remarcăm că diferențele dintre interfețe sunt destul de semnificative, interfața gestionată a fost complet reproiectată. În principiu, acestea sunt toate diferențele pe care le văd utilizatorii obișnuiți ai programului 1C. În ceea ce privește programatorii, interfața gestionată necesită scrierea codului modificat, deoarece dezvoltarea este deja efectuată în 1C 8.3, și nu în 1C 8.2, de aici toate consecințele care decurg. Codul trebuie, de asemenea, împărțit în client și server, acest lucru este indicat folosind directivele corespunzătoare din configurator.

Odată cu apariția platformei 1C Enterprise 8.2, mecanismul de dezvoltare a interfeței cu utilizatorul s-a schimbat semnificativ. A devenit posibil să se creeze formulare și aplicații gestionate (Figura 1).

Poza 1

În plus, este propus un nou sistem de împărțire a funcționalității între aplicația client și server.
Aplicația gestionată acceptă următoarele tipuri de clienți:

  • Client gros (mod de lansare normal și gestionat),
  • client slab,
  • Client web.

Mecanismul de creare a formularelor gestionate diferă semnificativ de cele convenționale. În primul rând, formularele gestionate se disting prin faptul că sunt create automat de sistem pe baza setărilor speciale, programatorul nu trebuie să deseneze fiecare formular în detaliu. Toate funcționalitățile formularului sunt descrise sub formă de detalii și comenzi. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate. Pentru fiecare metodă sau variabilă de formular trebuie specificată o directivă de compilare care determină locația de execuție (client sau server). Directivele de compilare pot fi după cum urmează:

  • &OnClient,
  • &Pe server,
  • &OnServerWithoutContext,
  • &OnClientOnServerWithoutContext.

De asemenea, un formular gestionat diferă de un formular obișnuit prin tipurile de date cu care lucrează. Dacă forma normală funcționează cu majoritatea tipurilor pe care 1C: Enterprise le oferă (inclusiv tipurile DirectoryObject, DocumentObject etc.), atunci în forma gestionată pot fi distinse următoarele categorii de tipuri:

  • tipurile care sunt utilizate direct în formular sunt acele tipuri care există pe partea clientului subțire și Web (de exemplu, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • tipuri care vor fi convertite în tipuri speciale de date — tipuri de date de formular gestionate. Astfel de tipuri sunt afișate în lista de detalii de formular între paranteze, de exemplu (DirectoryObject.Products);
  • lista dinamica.

Funcționarea formelor controlate are următoarele caracteristici distinctive (Figura 2):

  • Formularul există atât pe client, cât și pe server.

Realizează interacțiunea client-server (transferul datelor și proprietățile de proiectare ale elementelor).

  • Formularul nu funcționează cu obiectele aplicației


Figura 2

Formularul folosește obiecte universale speciale
Formulare de date(Figura 3).


Figura 3

Obiectele aplicației funcționează numai pe server și numai în timpul anumitor operațiuni.
La deschiderea formularului:

  • Obiectul este citit din baza de date,
  • Obiectul este convertit în date de formular,
  • Obiectul este eliminat (din memorie),
  • Datele formularului sunt trimise clientului.

La înregistrare:

  • Datele formularului sunt obținute de la client,
  • Datele din formular sunt convertite într-un obiect,
  • Obiectul este scris în baza de date,
  • Obiectul este eliminat (din memorie).

Să presupunem că există procesare externă scrisă pentru versiunea 8.1. Este posibil să-l rulați în 8.2, astfel încât să funcționeze cu forma sa mai veche, neadministrată? Procesarea este necesară o singură dată, pentru a transfera date și nu doriți să creați un formular gestionat pentru aceasta doar o dată...

Pentru procesarea externă (deschisă dintr-un fișier separat) în modul gestionat, utilizarea formularelor obișnuite nu este acceptată. Prin urmare, dacă într-o configurație care funcționează în modul gestionat, este necesar să începeți procesarea cu un formular negestionat și nu doriți să creați un formular nou, gestionat pentru această procesare, atunci o astfel de procesare trebuie mai întâi inclusă în configurație.

Formularele obișnuite (negestionate) pot funcționa numai în clientul gros. Clienții subțiri și web acceptă numai formulare gestionate.

Prin urmare, dacă trebuie să deschideți un formular de procesare obișnuit în interfața aplicației gestionate, atunci acest lucru este posibil numai într-un client gros care rulează în modul aplicație gestionată.

Cel mai simplu mod este lansarea clientului gros în modul aplicație gestionată din configurator, specificând acest lucru în parametri: Serviciu - Opțiuni - Lansare 1C:Enterprise - De bază - Client gros (aplicație gestionată).

Trebuie reținut că lansarea clienților în modul gestionat este posibilă numai dacă configurația are compatibilitatea cu versiunea 8.1 dezactivată (proprietate Mod de compatibilitate).

Cu toate acestea, acest lucru nu este suficient pentru ca platforma să deschidă forma veche, negestionată de procesare.

Capacitatea de a utiliza forme obișnuite într-un mod controlat este reglementată de o proprietate specială de configurare - Utilizați formulare normale într-o aplicație gestionată. Această proprietate trebuie setată.

În paleta de proprietăți de configurare, această proprietate nu este întotdeauna afișată, ci numai dacă în parametrii configuratorului este selectat modul de editare a configurației Aplicație gestionată și aplicație obișnuită ( Service - Opțiuni - General).

Și, în sfârșit, obiectul a cărui formă normală doriți să o vedeți în modul gestionat trebuie să aibă o singură formă de obiect principal, iar această formă trebuie să fie normală, neadministrată.

În alte cazuri (dacă obiectul nu are nicio formă principală sau obiectul are un formular principal gestionat), platforma va genera sau deschide (dacă are unul) formularul gestionat în mod implicit.

Problema principală este că peste 10-15 ani a fost deja compilat o mulțime de cod pentru forme obișnuite. Nimeni nu vrea să rescrie toate acestea pe client-server + mulți oameni sunt instruiți să lucreze cu interfața. Tranziția obligatorie la BP 3.0 începând de anul viitor creează panică în mintea dezvoltatorilor și contabililor. Feedback-ul va fi foarte neplăcut. În plus, ștacheta de intrare în profesie crește, programarea este mai dificilă, iar cele standard au devenit și mai dificile. Care este costul noului algoritm în documentele standard? UV arată grozav când ai 2-3 butoane pe documente, UV este grozav pentru a lucra pe dispozitive mobile, dar doar 0,01% dintre companii îl folosesc. Va trebui să schimbați dacă 1C nu vine cu ceva nou, dar va fi lung și dureros pentru toată lumea. Și companiile însele vor trebui să plătească banii.

Și eu, până acum, am experimentat doar lucruri negative din forme controlate, iată mai multe dezavantaje ale inovației:

  • Nimic? Ei bine, am dat peste asta de câteva ori, de exemplu, scriind și atașând un formular de imprimare extern la conf. ZUP, procesarea este o întreagă epopee, plină de instrucțiuni pe Internet și pagini de cod ar trebui.
    pe un client gros există o procedură cu parametri, adică dezvoltarea este o chestiune de minute.
    iar frânele sunt subțiri vizibile cu ochiul liber
  • Cât despre posibilitatea de a pregăti forme gestionabile - aceasta este artă de dragul artei, dar care este punctul practic, mai ales pentru versiunea fișierului?
  • Am sculptat în UV timp de 3 ani, dar acum am revenit la forme simple și credeți-mă, această tranziție a fost destul de dificil de făcut din punct de vedere psihologic, dar aceasta este alegerea mea conștientă pentru că ceea ce oferă 1c în UV este complet UG.... poate că peste câțiva ani 1c va face o descoperire, dar acum ea caută doar locul unde să facă această descoperire...
  • UV-urile din configurator durează mult mai mult să se deschidă.
    După aceea, deschiderea formularelor în 8.1 este ca transferul de la un camion la un avion!
  • Sunt mai multe probleme pentru toată lumea, utilizatorii sunt șocați de noua interfață (nu toată lumea recunoaște, dar sunt mult mai proști în privința lucrurilor mai mici), jumătate dintre programatori au devenit nepotriviți pentru profesionalism, specialistului obișnuit i-a devenit mai greu. găsi un loc de muncă și cum să produci un produs de calitate. Iar cea mai tare temă de marketing a UV este că se ridică peste tot, încât tranziția are loc cu o simplă actualizare, dar toată lumea uită că de la început trebuie să ajungi din urmă cu cele mai recente lansări! Dar in principiu imi place ideea!
  • Nu știu, experiența mea arată contrariul. Acolo unde boom-urile în forme stricte se lovesc automat de câțiva ani, în noile standard UV în fiecare lună începe „de ce, unde este 1C acum după actualizarea acestui buton și de ce acum nu funcționează”, ceea ce, vezi tu , nu adaugă viteză.
  • - există mai mult cod
    - codul a devenit mai complex
    — modificarea celor standard este mult mai dificilă
    - utilizatorii cărora le-am dat UT11 nu au găsit avantaje față de 10.x
    - dar au găsit unele încetiniri și o lipsă a unor funcții precum căutarea (din anumite motive au vrut căutare înainte-înapoi și nu selecție)
    Părerea mea este că sacrificiile sunt prea mari de dragul clientului web și al tabletelor. În plus, personal, nu am văzut încă deloc lucru real cu un client web, care trebuie să folosească cu succes accesul de la distanță
  • Bedlam client-server ar trebui să ofere o creștere a performanței și scalabilității, în timp ce, în același timp, costurile includ o creștere a codării.
    Cu toate acestea, nu toată lumea a cunoscut o creștere, de unde și dezamăgirea. Și, în același timp, toată lumea era aplecată pe costurile de codare.
    P.S. De fapt, îmi plac cele controlate, desenez calm pe ele. Dar cele tipice au devenit pervertite.
  • Acasă (computer normal) îmi conduc băutura conform întreprinzătorilor individuali.
    8.3, BP3, în carouri. Impresia principală este că nu lucrez, dar aștept tot timpul. răspunsul hemoroidal. SALT pentru cont se formează la fel de simplu - pare un card de cont pentru anul într-un mega-holding.
  • UT11 este o frână sălbatică, groază și, în general, un coșmar.
    UT10 zboară în comparație cu UT11.
    În ceea ce privește UV - bug-urile sunt infestate de ani de zile, totul este strâmb, coloanele nu încap niciodată pe un ecran, întinderea este groaznică în multe cazuri.
    Și încă pot enumera o mulțime de minusuri, dar probabil că nu voi spune nimic despre plusuri. Pur și simplu nu există.
    Firmele au ajuns în mod special cu aceste forme, pentru că dezvoltarea costă mai mult, nu existau speciale și nu există normale.

Sunt puține avantaje, dar desigur că există...

pro:

Răspunsul a fost acolo de mult timp, ceea ce a dat UP:

client multiplatform

  • lucrând pe linii de comunicare proaste
  • capacitatea de a lucra printr-un browser (fără a instala un client)

Și Data Transfer Object la structurarea codului, sub formă controlată în mediul 1C 8.2.

Introducere

Să începem cu o scurtă descriere a conceptului de „formă gestionată” și a conceptelor conexe ale platformei 1C. Cunoscătorii de platforme pot sări peste această secțiune.

În 2008, a devenit disponibilă o nouă versiune a platformei 1C: Enterprise 8.2 (denumită în continuare Aplicația Gestionată), care schimbă complet întregul nivel de lucru cu interfața. Aceasta include interfața de comandă, formularele și sistemul de ferestre. În același timp, nu numai că se schimbă modelul de dezvoltare a interfeței cu utilizatorul în configurație, dar este propusă și o nouă arhitectură de separare a funcționalității între aplicația client și server.
Aplicația gestionată acceptă următoarele tipuri de clienți:

  • Client gros (mod de lansare obișnuit și gestionat)
  • Client slab
  • Client web
Aplicația gestionată utilizează formulare construite pe tehnologie nouă. Sunt chemați Formulare gestionate. Pentru a ușura tranziția, sunt acceptate și formularele anterioare (așa-numitele formulare Regular), dar funcționalitatea lor nu este dezvoltată și sunt disponibile doar în modul de lansare a clientului gros.
Principalele diferențe ale formularelor gestionate pentru un dezvoltator:
  • Descriere declarativă, nu „pixel cu pixel” a structurii. Amplasarea specifică a elementelor este efectuată automat de către sistem atunci când formularul este afișat.
  • Toate funcționalitățile formularului sunt descrise ca DetaliiȘi echipe. Detaliile sunt datele cu care funcționează formularul, iar comenzile sunt acțiunile care trebuie efectuate.
  • Formularul rulează atât pe server, cât și pe client.
  • În contextul clientului, aproape toate tipurile de aplicații sunt indisponibile și, în consecință, este imposibil să se modifice datele din baza de informații.
  • Pentru fiecare metodă sau variabilă de formă, aceasta trebuie specificată directivă de compilare, definirea locației de execuție (client sau server) și accesul la contextul formularului.
Să enumerăm directivele pentru compilarea metodelor de formulare:
  • &OnClient
  • &Pe server
  • &OnServerWithout Context
  • &OnClientOnServerWithout Context
Să ilustrăm cele de mai sus. Captura de ecran arată un exemplu de formular gestionat și modulul său în modul de dezvoltare. Găsiți descrierea declarativă, elementele de recuzită, directivele de compilare etc.

Toate discuțiile ulterioare vor fi despre partea dreaptă a ilustrației, despre cum să structurați codul modulului și ce principii vă vor permite să implementați interacțiunea eficientă client-server.

Să definim problema

Au trecut câțiva ani de când noua versiune a platformei 1C este utilizată în mod activ și multe soluții (configurații) au fost lansate atât de 1C, cât și de numeroșii săi parteneri.
În acest timp, dezvoltatorii au dezvoltat o înțelegere comună a principiilor interacțiunii client-server la crearea formularelor și s-a schimbat abordarea implementării modulelor software în noile realități arhitecturale?

Să ne uităm la structura codului (modul formular) în mai multe forme ale aceleiași configurații standard și să încercăm să găsim modele.
Prin structură înțelegem secțiuni de cod (cel mai adesea acestea sunt blocuri de comentarii) alocate de dezvoltator pentru a grupa metode și directive de compilare pentru aceste metode.
Exemplul 1:
Secțiunea de gestionare a evenimentelor Metoda - pe client Metoda - pe server Metoda - pe client Secțiunea proceduri și funcții de service Funcții auxiliare de control al intrărilor
Exemplul 2:
Proceduri și funcții de service Documente de plată Valori Manipulatori de evenimente
Exemplul 3:
Proceduri de service pe server Proceduri de service pe client Proceduri de service pe server fără context.
Exemplul 4:
Proceduri de uz general Manipulatori de evenimente de formulare Proceduri ale subsistemului „informații de contact”.
În esență, structura codului lipsește sau, pentru a spune ușor, este similară cu ceea ce era în Forms 8.1:

  • Cuvinte neinformative „General, Serviciu, Auxiliar”.
  • Încercări timide de a separa metodele client și server.
  • Metodele sunt adesea grupate pe elemente de interfață „Lucrul cu partea tabelară Produse, Informații de contact”.
  • Aranjamentul arbitrar al metodelor și grupurilor de coduri. De exemplu, Event Handlers pot fi în partea de sus într-o formă, în partea de jos într-o alta, deloc evidențiate într-o a treia, etc.
  • Și să nu uităm că toate acestea sunt într-o singură configurație.
  • Da, există configurații în care cuvintele „General, Service, Auxiliar” sunt întotdeauna în aceleași locuri, dar...
De ce aveți nevoie de structură de cod?
  • Simplificarea întreținerii.
  • Simplificați învățarea.
  • Înregistrarea principiilor generale/importante/de succes.
  • ...opțiunea ta
De ce nu ajută standardul de dezvoltare existent de la 1C?
Să ne uităm la principiile publicate pe discuri ITS și în diverse „Ghiduri pentru dezvoltatori...” care sunt recomandate atunci când scrieți un formular gestionat.
  • Minimizați numărul de apeluri pe server.
  • Calcul maxim pe server.
  • Apelurile non-contextuale ale serverului sunt mai rapide decât cele contextuale.
  • Program cu comunicarea client-server în minte.
  • și așa mai departe.
Acestea sunt sloganuri care sunt absolut adevărate, dar cum să le implementăm? Cum să minimizezi numărul de apeluri, ce înseamnă să programezi în modul client-server?

Modele de design sau înțelepciune generațională

Interacțiunea client-server a fost folosită în diverse tehnologii software de zeci de ani. Răspunsul la întrebările prezentate în secțiunea anterioară este cunoscut de mult și este rezumat în două principii de bază.
  • Fațada la distanță(denumită în continuare interfață de acces la distanță)
  • Obiect de transfer de date(denumit în continuare obiect de transfer de date)
Un cuvânt de la Martin Fowler, descrierea sa a acestor principii:
  • … Fiecare obiect potențial destinat accesului de la distanță trebuie să aibă interfață cu granularitate scăzută, care va minimiza numărul de apeluri necesare pentru a efectua o anumită procedură. ... În loc să solicitați o factură și toate articolele ei separat, trebuie să citiți și să actualizați toate elementele facturii într-o singură solicitare. Acest lucru afectează întreaga structură a obiectului... Amintiți-vă: interfața de acces la distanță nu conține logica domeniului.
  • ...dacă aș fi o mamă grijulie, cu siguranță i-aș spune copilului meu: „Nu scrie niciodată obiecte de transfer de date!” În cele mai multe cazuri, obiectele de transfer de date nu sunt altceva decât set câmp umflat... Valoarea acestui monstru dezgustător constă numai în posibilitatea transmite mai multe informații prin rețea într-un singur apel- o tehnică de mare importanță pentru sistemele distribuite.
Exemple de șabloane în platforma 1C
Interfața de programare a aplicației disponibilă dezvoltatorului atunci când dezvoltă un formular gestionat conține multe exemple ale acestor principii.
De exemplu, metoda OpenForm(), o interfață tipică „aspră”.
Parametri de deschidere = Structură nouă(„Parametru1, Parametru2, Parametru3”, Valoare1, Valoare2, Valoare3); Form = OpenForm(FormName, OpeningParameters);
Comparați cu stilul adoptat în v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

În contextul unui formular gestionat, există multe „Obiecte de transfer de date”. Puteți selecta sistemicăȘi definit de dezvoltator.
Cei de sistem modelează un obiect de aplicație pe client, sub forma unuia sau mai multor elemente de date de formular. Este imposibil să le creați fără referire la detaliile formularului.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Conversia obiectelor de transfer de date de sistem în tipuri de aplicații și invers se realizează folosind următoarele metode:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Adesea, conversia explicită este utilizată atunci când se adaptează o soluție existentă. Metodele se pot aștepta (utiliza caracteristici) parametri de intrare, cum ar fi ValueTable, mai degrabă decât FormDataCollection, sau metoda a fost definită în contextul unui obiect aplicație și a devenit indisponibilă pentru apelul direct din formular.
Exemplul 1C v8.1:
// pe client în contextul formularului FillUserCache(DepartmentLink)
Exemplul 1C v8.2:
// pe server în contextul formularului ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueÂFormAttributes(ProcessingObject, "Object");

Obiectele de transfer de date, a căror structură este determinată de dezvoltator, sunt un mic subset al tipurilor disponibile atât pe client, cât și pe server. Cel mai adesea, următoarele sunt utilizate ca parametri și rezultate ale metodelor unei interfețe „groșate”:

  • Tipuri primitive (șir, număr, boolean)
  • Structura
  • Corespondenţă
  • Matrice
  • Legături către obiectele aplicației (identificator unic și reprezentare text)
Exemplu: metoda acceptă o listă de comenzi pentru schimbarea statutului și returnează clientului o descriere a erorilor.
&OnServerWithoutContext Funcția ServerChangeOrderStatus(Comenzi, NewStatus) Erori = Potrivire nouă(); // [comanda][descrierea erorii] Pentru fiecare comandă din ciclul comenzi StartTransaction(); Încercați DocOb = Order.GetObject(); …. alte actiuni, posibile nu numai cu comanda... Exceptie CancelTransaction(); Errors.Insert(Comandă, ErrorDescription()); EndTempt; EndCycle; Eroare de returnare; EndFunction // ServerChangeOrderStatus()

Structurarea codului

Principalele obiective pe care trebuie să le reflecte modulul de formulare gestionate și abordări ale soluției.
  • Separare clară a codului client și server. Să nu uităm că la momentul execuției acestea sunt două procese care interacționează, fiecare dintre ele având funcționalități disponibile semnificativ diferite.
  • Identificarea clară a interfeței de acces la distanță, ce metode de server pot fi apelate de la client și care nu? Numele metodelor de interfață la distanță încep cu prefixul „Server”. Acest lucru vă permite să vedeți imediat transferul de control către server în timp ce citiți codul și simplifică utilizarea ajutorului contextual. Rețineți că recomandarea oficială (ITS) sugerează metode de denumire cu postfixe, de exemplu, ChangeOrderStatusOnServer(). Cu toate acestea, să repetăm, nu toate metodele de server pot fi apelate de la client și, prin urmare, accesibilitatea logică este mai importantă decât locația de compilare. Prin urmare, cu prefixul „Server” marchem doar metodele disponibile pentru client, să numim metoda exemplu ServerChangeOrderStatus().
  • Lizibilitate. O chestiune de gust, acceptăm comanda atunci când modulul începe cu proceduri de creare a unui formular pe server și metode de acces la distanță.
  • Mentenabilitatea. Trebuie să existe o locație clară pentru adăugarea unui cod nou. Un punct important este că șabloanele de metodă create automat de configurator sunt adăugate la sfârșitul modulului. Deoarece manipulatorii de evenimente pentru elementele de formular sunt cel mai adesea creați automat, blocul corespunzător este situat ultimul, pentru a nu trage fiecare handler în alt loc din modul.
Mai jos este structura de bază a modulului care implementează obiectivele enumerate.
  • Opțiune grafică – arată clar fluxul principal de execuție.
  • Opțiunea text este un exemplu de design șablon pentru inserarea rapidă a unei structuri într-un nou modul de formular.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="„Data=""/> // <Описание> // // //////////////////////////////////////////////////////////////////// ////////////////////////////// VARIABILE DE MODUL ////////////////// // ////////////////////////////////////////////////////////////////////// ////////// // PE SERVER //******* EVENIMENTE PE SERVER ******* &Pe Procedura Server când este creată pe server (Eșec, Procesare standard) / /Inserați conținutul handler-ului Sfârșitul procedurii //******* INTERFAȚA DE ACCES LA DISTANȚĂ ******* //******* LOGICA DE AFACERI PE SERVER ******* ///////// ///////////////////////////////////////////////////////////// /////// //////////////////// // METODE COMUNE DE CLIENT ȘI SERVER ///////////////// /////// /////////////////////////////////////////////////////////////// ///// //////// // PE CLIENT //******* LOGICA DE AFACERI PE CLIENT ******* //******* ECHIPA * ****** //******* EVENIMENTE CLIENȚI ******* //////////////////////////// ///// ///////////////////////////////////////////////////////////////// // / / PRINCIPALI OPERATORI DE PROGRAM

Întrebări înrudite
În concluzie, vom schița câteva domenii la care este util să ne gândim atunci când programați interacțiunea client-server.
  • Opțiuni de implementare a interfeței de acces la distanță. Asincronie, nivel de detaliu...
  • Memorarea în cache. 1C a luat o decizie arhitecturală nereușită, introducând memorarea în cache doar la nivelul metodelor de apelare ale modulelor comune și neasigurând capabilități de control (timp de relevanță, resetare la cerere).
  • Apeluri implicite pe server. Nu uitați de caracteristicile tehnologice multe operațiuni „inofensive” pe client provoacă platforma să contacteze serverul.


 

Ar putea fi util să citiți: