Salut, Habr!
În acest articol, vom începe povestea despre cum este structurat interior și ce tehnologii sunt folosite în dezvoltarea sa.
De ce considerăm că este interesant? În primul rând, pentru că platforma „1C:Enterprise 8” este o aplicație vastă (peste 10 milioane de linii de cod) scrisă în C++ (client, server etc.), JavaScript (client web) și, de curând, și . Proiectele mari sunt interesante măcar prin prisma dimensiunii lor, deoarece problemele care trec neobservate în o bază de cod mică devin evidente în astfel de proiecte. În al doilea rând, „1C:Enterprise” este un produs replicabil, „boxat”, iar articolele despre astfel de dezvoltări pe Habr sunt destul de puține. De asemenea, este întotdeauna interesant să afli cum se descurcă alte echipe și firme.
Așadar, să începem. În acest articol, vom face un rezumat al unor tehnologii care sunt utilizate în platformă, conturând peisajul, fără a ne adânci prea mult în implementare. Deoarece pentru multe mecanisme, o poveste detaliată ar necesita un articol separat, iar pentru altele – o întreagă carte!
Pentru început, este important să ne stabilim lucrurile de bază – ce este platforma „1C:Enterprise” și din ce componente este formată. Răspunsul la această întrebare nu este simplu, deoarece prin termenul „Platformă” (pentru scurtare ne vom referi la ea în acest mod) se înțelege atât instrumentul de dezvoltare a aplicațiilor de afaceri, cât și mediul de execuție, precum și instrumentele de administrare. În mod arbitrar, putem distinge următoarele componente:
- cluster de servere
- client „subțire” capabil să se conecteze la server prin http și propriul său protocol binar
- client pentru lucrul într-o arhitectură cu două niveluri cu baza de date, plasată pe un hard disk sau pe un folder de rețea
- client web
- instrumente de administrare a serverului de aplicații
- mediul de dezvoltare (cunoscut ca Configurator)
- mediu de execuție 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țatul , scris în Java.
Aplicații native
Pentru dezvoltarea aplicațiilor native se folosește C++03. Pe Windows se utilizează compilatorul Microsoft Visual C++ 12 (profil compatibil cu Windows XP), iar pe Linux și Android — gcc 4.8, pentru iOS — clang 5.0. Biblioteca standard utilizată este comună pentru toate sistemele de operare și compilatoare — STLPort. Această soluție permite reducerea probabilității de erori specifice implementării STL. În prezent, planificăm tranziția către implementarea STL furnizată cu CLang, deoarece STLPort a încetat să-și dezvolte suportul și este incompatibil cu modul de suport C++11 activat în gcc.
Codul sursă al serverului este comun în proporție de 99%, iar al clientului — în proporție de 95%. Mai mult, chiar și platforma mobilă folosește același cod C++ ca și cea „mare”, deși acolo procentul de unificare este ceva mai mic.
Ca majoritatea utilizatorilor de C++, nu pretindem să folosim 100% din capacitățile limbajului și bibliotecilor sale. Astfel, practic nu folosim Boost, iar dintre capacitățile limbajului — realizarea dinamică a tipurilor. Totuși, aplicăm activ:
- STL (în special, șiruri, containere și algoritmi)
- moștenire multiplă, inclusiv moștenire multiplă a implementării
- șabloane
- excepții
- puncte de inteligență (implementare proprie)
Prin utilizarea moștenirii multiple a interfețelor (clase complet abstracte), devine posibilă modelul componentelor, despre care vom discuta mai jos.
Componente
Pentru asigurarea modularității, toată funcționalitatea este împărțită în componente, care sunt biblioteci dinamice (*.dll pe Windows, *.so — pe Linux). Există în total peste o sută cincizeci de componente, iată descrierile unora dintre ele:
backend
Conține „motorul” de metadate al platformei
accnt
Obiecte pe care dezvoltatorii aplicațiilor le folosesc pentru a construi contabilitatea (planuri contabile și registre de contabilitate)
bsl
Motorul de execuție al limbajului încorporat
nuke
Implementare proprie a alocării memoriei
dbeng8
Motorul bazei de date fișier. O mașină de baze de date simplă tip fișier-server, bazată pe ISAM, care include și un procesor SQL simplu.
wbase
Conține clase de bază și funcții pentru implementarea interfeței utilizator Windows — clase de feronerie, acces la GDI etc.
Împărțirea în mai multe componente este benefică din mai multe puncte de vedere:
- Împărțirea facilitează o mai bună proiectare, în special o mai bună izolare a codului
- Din setul de componente se pot asambla în mod flexibil diferite opțiuni de livrare:
- De exemplu, instalarea unui client subțire va conține wbase, dar nu va avea backend
- iar pe server, wbase nu va fi prezent, dimpotrivă
- ambele opțiuni vor conține, desigur, nuke și bsl
Toate componentele necesare pentru această variantă de pornire sunt încărcate la startul programului. Aceasta este, printre altele, necesară pentru înregistrarea claselor SCOM, despre care vom vorbi mai jos.
SCOM
Pentru decompunerea la un nivel mai mic se folosește sistemul SCOM — similar din punct de vedere ideologic cu biblioteca ATL. Pentru cei care nu au lucrat cu ATL, să enumerăm pe scurt principalele capacități și caracteristici.
Pentru o clasă SCOM special concepută:
- Oferă metode factory care permit crearea unei clase dintr-o altă componentă cunoscând doar numele acesteia (fără a dezvălui implementarea)
- Oferă infrastructura de pointere inteligente cu numărarea referințelor. Nu este necesar să urmăriți manual durata de viață a clasei SCOM
- Permite verificarea dacă un obiect implementează un anumit interfață și aduce automat pointerul pe obiect la pointerul pe interfață
- Crează un obiect-serviciu, întotdeauna disponibil prin metoda get_service etc.
De exemplu, se poate descrie într-o componentă json.dll o clasă pentru citirea JSON (de exemplu, JSONStreamReader).
Clasele, instanțele pot fi create din alte componente trebuie înregistrate în mașina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Această macrocomandă va descrie o clasă-statică specială de înregistrare, al cărei constructor va fi apelat la încărcarea componentei în memorie.
După aceasta, se poate crea instanța sa într-o altă componentă:
IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));
Pentru suportul serviciilor, SCOM oferă o infrastructură suplimentară, destul de complexă. Central în aceasta este conceptul de proces SCOM, care servește ca un container pentru serviciile pornite (adică îndeplinește rolul de Service Locator) și conține, de asemenea, legătura cu resursele localizabile. Procesul SCOM se leagă de firul OS. Datorită acestui lucru, în cadrul aplicației se pot obține serviciile astfel:
SCOM_Process* process = core::current_process();
if (process)
return get_service(process);
În plus, prin comutarea proceselor logice (SCOM) asociate cu fluxul, este posibil să obținem aplicații practic independente din punct de vedere al spațiului informațional, care se desfășoară în cadrul unui singur flux. Așa funcționează clientul nostru subțire, care lucrează cu o bază de date pe fișiere - în interiorul unui proces de sistem de operare există două procese SCOM, unul asociat cu clientul și celălalt cu serverul. Această abordare permite unificarea codului, care va funcționa atât pe baza de date locală pe fișiere, cât și în varianta „reală” client-server. Prețul acestei uniformități este reprezentat de cheltuielile indirecte, dar practica arată că acestea își merită costul.
Pe baza modelului componentelor SCOM sunt implementate atât logica de afaceri, cât și partea interfeței pentru 1C:Enterprise.
Interfața utilizatorului
Apropo de interfețe. Nu folosim controale standard Windows, elementele noastre de control sunt implementate direct pe API-ul Windows. Pentru versiunea Linux, a fost creată o interfață care funcționează prin biblioteca wxWidgets.
Biblioteca elementelor de control nu depinde de alte părți ale «1C:Enterprise» și o folosim și în alte câteva utilitare interne mici.
De-a lungul anilor, aspectul controalelor 1C:Enterprise s-a schimbat, dar o schimbare semnificativă a principiilor a avut loc doar o singură dată, în 2009, odată cu lansarea versiunii 8.2 și apariția «formelor gestionate». Pe lângă schimbarea aspectului, principiul fundamental de aranjare a formelor s-a schimbat - s-a renunțat la poziționarea pixel cu pixel în favoarea aranjamentului flow al elementelor. În plus, în noul model, elementele de control nu lucrează direct cu obiectele din domeniu, ci cu DTO speciale ().
Aceste modificări au permis crearea clientului web «1C:Enterprise», care replică logica controalelor C++ în JavaScript. Ne străduim să menținem echivalența funcțională între clientul subțire și cel web. În cazul în care acest lucru nu este posibil, de exemplu, din cauza constrângerilor impuse de API-ul JavaScript disponibil (de exemplu, capacitatea de a lucra cu fișiere este foarte limitată), adesea implementăm funcționalitatea necesară cu extensii de browser scrise în C++. În prezent, susținem Internet Explorer și Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows și Linux) și Safari (MacOS).
În plus, tehnologia formularelor gestionate este utilizată pentru a crea interfața aplicațiilor mobile pe platforma 1C. Pe dispozitivele mobile, randarea controalelor este realizată folosind tehnologii „native” pentru sistemul de operare, dar pentru logica de aranjare a formularului și reacția interfeței se folosește același cod ca și în „marele” platformă „1C:Enterprise”.
Interfața 1C pe sistemul de operare Linux
Interfața 1C pe dispozitivul mobil
Interfața 1C pe alte platforme 
Interfața 1C pe sistemul de operare Windows
Interfața 1C — client web
Open source
Deși nu folosim biblioteci standard pentru dezvoltatorii C++ pe Windows (MFC, controale din WinAPI), nu toate componentele sunt scrise de noi. A fost menționată deja biblioteca , și folosim, de asemenea:
- pentru a lucra cu HTTP și FTP.
- pentru a lucra cu criptografia și a stabili conexiuni TLS
- pentru analizarea XML-ului
- pentru a lucra cu protocoalele poștale (POP3, SMTP, IMAP)
- pentru a analiza mesajele de poștă electronică
- pentru a stoca jurnalele activității utilizatorilor
- pentru internaționalizare
Lista poate continua.
În plus, folosim versiuni foarte modificate și în timpul dezvoltării testelor unitare.
Bibliotecile au necesitat adaptări pentru a fi compatibile cu modelul SCOM al organizației componentelor.
Răspândirea platformei 1C face ca aceasta să fie o verificare excelentă pentru bibliotecile utilizate. Diversitatea utilizatorilor și scenariilor descoperă rapid erorile chiar și în cele mai rar utilizate părți ale codului. Le corectăm la noi și încercăm să le returnăm autorilor bibliotecilor. Experiența interacțiunii variază foarte mult.
Dezvoltatori și reacționează rapid la pull-request-uri, dar patch-ul, de exemplu, în nu am reușit să-l trimitem.
Concluzie
În acest articol, am abordat câteva aspecte esențiale ale dezvoltării platformei „1C: Enterprise”. În paginile limitate ale articolului, am discutat doar despre unele aspecte interesante, din punctul nostru de vedere.
O descriere generală a diferitelor mecanisme ale platformei poate fi vizualizată .
Ce teme ar fi interesante pentru tine în următoarele articole?
Cum este realizată platforma mobilă 1C?
Descrierea structurii interne a clientului web?
Sau, poate, ești interesat de procesul de selecție a funcționalităților pentru noile versiuni, dezvoltare și testare?
Scrie în comentarii!
Sursa: habr.com
