Hei Habr!
În acest articol vom începe povestea despre cum funcționează în interior și ce tehnologii sunt folosite în dezvoltarea sa.
De ce credem că acest lucru este interesant? În primul rând, pentru că platforma 1C:Enterprise 8 este o aplicație mare (mai mult de 10 milioane de linii de cod) în C++ (client, server etc.), JavaScript (client web) și, mai recent, Și . Proiectele mari pot fi interesante cel puțin datorită amplorii lor, deoarece problemele care sunt invizibile într-o bază de cod mică apar cu forță în astfel de proiecte. În al doilea rând, „1C:Enterprise” este un produs replicabil, „în cutie”, și există foarte puține articole despre astfel de evoluții pe Habré. De asemenea, este întotdeauna interesant să știi cum este viața în alte echipe și companii.
Asadar, haideti sa începem. În acest articol vom oferi o privire de ansamblu asupra unora dintre tehnologiile care sunt utilizate în platformă și vom schița peisajul, fără a ne scufunda adânc în implementare. Într-adevăr, pentru multe mecanisme, o poveste detaliată ar necesita un articol separat, iar pentru unii, o carte întreagă!
Pentru început, merită să decideți asupra lucrurilor de bază - ce este platforma 1C:Enterprise și din ce componente constă. Răspunsul la această întrebare nu este atât de simplu, deoarece termenul „Platformă” (pentru concizie, îl vom numi așa) se referă la un mijloc de dezvoltare a aplicațiilor de afaceri, un mediu de rulare și instrumente de administrare. Următoarele componente pot fi distinse aproximativ:
- cluster de servere
- client „subțire” capabil să se conecteze la server prin http și propriul protocol binar
- client pentru lucrul într-o arhitectură cu două niveluri cu o bază de date situată pe un hard disk sau un folder de rețea
- client web
- instrumente de administrare a serverului de aplicații
- mediu de dezvoltare (cunoscut sub numele de Configurator)
- mediu de rulare pentru iOS, Android și Windows Phone (platforma mobilă 1C)
Toate aceste părți, cu excepția clientului web, sunt scrise în C++. În plus, există recent anunțat , scris în Java.
Aplicații native
C++03 este folosit pentru a dezvolta aplicații native. Pentru Windows, Microsoft Visual C++ 12 (un profil compatibil cu Windows XP) este folosit ca compilator, iar pentru Linux și Android - gcc 4.8, pentru iOS - clang 5.0. Biblioteca standard utilizată este aceeași pentru toate sistemele de operare și compilatoare - STLPort. Această soluție reduce probabilitatea erorilor specifice implementării STL. În prezent, plănuim să migrăm la implementarea STL livrată cu CLang, deoarece STLPort a fost întrerupt și este incompatibil cu modul C++11 activat al gcc.
Baza de cod a serverului este comună în proporție de 99%, cea a clientului - 95%. Mai mult, chiar și platforma mobilă folosește același cod C++ ca și cel „mare”, deși procentul de unificare acolo este ceva mai mic.
La fel ca majoritatea utilizatorilor C++, nu pretindem că folosim 100% din capabilitățile limbajului și ale bibliotecilor sale. Deci, practic nu folosim Boost, iar una dintre caracteristicile limbajului este turnarea de tip dinamic. În același timp, folosim în mod activ:
- STL (în special șiruri de caractere, containere și algoritmi)
- moștenire multiplă, incl. moștenirea implementării multiple
- Șabloane
- excepții
- indicatoare inteligente (implementare personalizată)
Prin utilizarea moștenirii multiple a interfețelor (clase complet abstracte), devine posibil un model de componentă, care va fi discutat mai jos.
Componente
Pentru a asigura modularitatea, toată funcționalitatea este împărțită în componente, care sunt biblioteci dinamice (*.dll pentru Windows, *.so pentru Linux). Există mai mult de o sută cincizeci de componente în total; iată descrieri ale unora dintre ele:
backend
Conține motorul de metadate ale platformei
accnt
Obiecte pe care dezvoltatorii de aplicații le folosesc pentru a construi înregistrări contabile (planuri de conturi și registre contabile)
bsl
Motor de execuție a limbajului încorporat
nucă
Implementare personalizată a alocătorului de memorie
dbeng8
Motor de bază de date de fișiere. Un simplu motor de bază de date server de fișiere bazat pe ISAM, care include și un procesor SQL simplu
wbase
Conține clasele de bază și funcțiile pentru implementarea interfeței utilizator Windows - clase de ferestre, acces GDI etc.
Împărțirea în mai multe componente este utilă din mai multe puncte de vedere:
- Separarea promovează un design mai bun, în special o mai bună izolare a codului
- Dintr-un set de componente puteți asambla în mod flexibil diferite opțiuni de livrare:
- De exemplu, o instalare de client subțire va conține wbase, dar nu va avea backend
- dar pe serverul wbase, dimpotrivă, nu va fi
- ambele opțiuni vor conține, desigur, nuke și bsl
Toate componentele necesare pentru această opțiune de lansare sunt încărcate la pornirea programului. Acest lucru, în special, este necesar pentru înregistrarea cursurilor SCOM, care vor fi discutate mai jos.
SCOM
Pentru descompunerea la un nivel inferior se folosește sistemul SCOM, o bibliotecă asemănătoare ca ideologie cu ATL. Pentru cei care nu au lucrat cu ATL, enumeram pe scurt principalele capabilități și caracteristici.
Pentru o clasă SCOM special concepută:
- Oferă metode din fabrică care vă permit să creați o clasă dintr-o altă componentă cunoscând doar numele acesteia (fără a dezvălui implementarea)
- Oferă o infrastructură de indicator inteligent de numărare a referințelor. Durata de viață a clasei SCOM nu trebuie monitorizată manual
- Vă permite să aflați dacă un obiect implementează o anumită interfață și să convertiți automat un pointer către obiect într-un pointer către interfață
- Creați un obiect de serviciu care este întotdeauna accesibil prin metoda get_service etc.
De exemplu, puteți descrie o clasă pentru citirea JSON (de exemplu, JSONStreamReader) în componenta json.dll.
Clasele și instanțele pot fi create din alte componente; acestea trebuie să fie înregistrate în mașina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Această macrocomandă va descrie o clasă specială de înregistrare statică, al cărei constructor va fi apelat atunci când componenta este încărcată în memorie.
După aceasta, puteți crea o instanță a acesteia într-o altă componentă:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Pentru a sprijini serviciile, SCOM oferă o infrastructură suplimentară, destul de complexă. Central pentru acesta este conceptul unui proces SCOM, care servește ca un container pentru rularea serviciilor (adică joacă rolul de Localizare de servicii) și conține, de asemenea, o legătură cu resursele localizate. Procesul SCOM este legat de firul OS. Datorită acestui fapt, în interiorul aplicației puteți primi servicii de genul acesta:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Mai mult, prin comutarea proceselor logice (SCOM) legate de un thread, puteți obține aplicații care sunt practic independente din punct de vedere al spațiului de informații, rulând în cadrul aceluiași thread. Așa funcționează clientul nostru subțire cu o bază de date de fișiere - în interiorul unui proces OS există două procese SCOM, unul asociat cu clientul și al doilea cu serverul. Această abordare ne permite să unificăm scrierea codului care va funcționa atât pe baza de date locală de fișiere, cât și în versiunea „real” client-server. Prețul pentru o astfel de uniformitate este peste cap, dar practica arată că merită.
Pe baza modelului de componentă SCOM, sunt implementate atât logica de afaceri, cât și partea de interfață a 1C: Enterprise.
Interfața cu utilizatorul
Apropo, despre interfețe. Nu folosim controale standard Windows; controalele noastre sunt implementate direct în API-ul Windows. Pentru versiunea Linux, a fost realizat un strat care funcționează prin biblioteca wxWidgets.
Biblioteca de controale nu depinde de alte părți ale 1C:Enterprise și este folosită de noi în câteva alte mici utilități interne.
De-a lungul anilor de dezvoltare a 1C:Enterprise, aspectul controalelor s-a schimbat, dar o schimbare serioasă a principiilor a avut loc o singură dată, în 2009, odată cu lansarea versiunii 8.2 și apariția „formularelor gestionate”. Pe lângă schimbarea aspectului, principiul aspectului formularului s-a schimbat fundamental - a existat o respingere a poziționării pixel-cu-pixel a elementelor în favoarea aspectului flux al elementelor. În plus, în noul model, controalele nu funcționează direct cu obiectele de domeniu, ci cu DTO-uri speciale ().
Aceste modificări au făcut posibilă crearea unui client web 1C:Enterprise care reproduce logica C++ a controalelor JavaScript. Încercăm să menținem echivalența funcțională între clienții thin și web. În cazurile în care acest lucru nu este posibil, de exemplu din cauza limitărilor API-ului JavaScript disponibil (de exemplu, capacitatea de a lucra cu fișiere este foarte limitată), implementăm adesea funcționalitatea necesară folosind extensii de browser scrise în C++. În prezent, acceptăm Internet Explorer și Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows și Linux) și Safari (MacOS).
În plus, tehnologia de formulare gestionate este utilizată pentru a crea o interfață pentru aplicațiile mobile pe platforma 1C. Pe dispozitivele mobile, redarea controalelor este implementată folosind tehnologii native sistemului de operare, dar pentru logica aspectului formularului și răspunsul interfeței, se folosește același cod ca și în platforma „mare” 1C:Enterprise.
Interfață 1C pe sistemul de operare Linux
Interfață 1C pe un dispozitiv mobil
Interfață 1C pe alte platforme
Interfață 1C pe sistemul de operare Windows
Interfața 1C - client web
Sursa deschisa
Deși nu folosim biblioteci standard pentru dezvoltatorii C++ sub Windows (MFC, controale din WinAPI), nu scriem singuri toate componentele. Biblioteca a fost deja menționată , și mai folosim:
- pentru lucrul cu HTTP și FTP.
- pentru lucrul cu criptografie și stabilirea conexiunilor TLS
- pentru analiza XML
- pentru lucrul cu protocoale de e-mail (POP3, SMTP, IMAP)
- pentru a analiza mesajele de e-mail
- pentru stocarea jurnalelor utilizatorilor
- pentru internaţionalizare
Lista continuă.
În plus, folosim o versiune foarte modificată и la elaborarea testelor unitare.
Bibliotecile au necesitat adaptare pentru a fi compatibile cu modelul de organizare a componentelor SCOM.
Prevalența 1C face din platformă un test excelent de rezistență pentru bibliotecile utilizate în ea. O varietate de utilizatori și scenarii dezvăluie rapid erori chiar și în cele mai rar utilizate zone de cod. Le corectăm singuri și încercăm să le dăm înapoi autorilor bibliotecii. Experiența interacțiunii se dovedește a fi foarte diferită.
Dezvoltatorii и răspunde rapid la solicitările de tragere, dar patch-ul, de exemplu, intră Nu am reușit niciodată să-l dăm înapoi.
Concluzie
În articol am atins câteva aspecte principale ale dezvoltării platformei 1C: Enterprise. În domeniul limitat al articolului, am atins doar câteva aspecte interesante, după părerea noastră.
O descriere generală a diferitelor mecanisme ale platformei poate fi găsită .
Ce subiecte v-ar interesa în articolele viitoare?
Cum este implementată platforma mobilă 1C?
Descrierea structurii interne a clientului web?
Sau poate sunteți interesat de procesul de selectare a funcțiilor pentru noile versiuni, dezvoltare și testare?
Scrieți în comentarii!
Sursa: www.habr.com