Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?
Hoy Habr!
Sa artikulong ito sisimulan natin ang kuwento tungkol sa kung paano ito gumagana sa loob platform "1C:Enterprise 8" at kung anong mga teknolohiya ang ginagamit sa pag-unlad nito.
"manipis" na kliyente na may kakayahang kumonekta sa server sa pamamagitan ng http at sarili nitong binary protocol
client para sa pagtatrabaho sa isang two-tier architecture na may database na matatagpuan sa isang hard drive o network folder
web client
mga tool sa pangangasiwa ng server ng application
development environment (kilala bilang Configurator)
runtime environment para sa iOS, Android at Windows Phone (mobile platform 1C)
Ang lahat ng mga bahaging ito, maliban sa web client, ay nakasulat sa C++. Bukod pa rito, mayroong kamakailang inihayag Bagong henerasyon configurator, nakasulat sa Java.
Mga katutubong app
Ang C++03 ay ginagamit upang bumuo ng mga katutubong application. Para sa Windows, ginagamit ang Microsoft Visual C++ 12 (isang profile na katugma sa Windows XP) bilang compiler, at para sa Linux at Android - gcc 4.8, para sa iOS - clang 5.0. Ang karaniwang library na ginamit ay pareho para sa lahat ng mga operating system at compiler - STLPort. Binabawasan ng solusyong ito ang posibilidad ng mga error na partikular sa pagpapatupad ng STL. Kasalukuyan kaming nagpaplanong lumipat sa pagpapatupad ng STL na ipinadala kasama ng CLang, dahil ang STLPort ay hindi na ipinagpatuloy at hindi tugma sa C++11 na mode na pinagana ng gcc.
Ang code base ng server ay 99% karaniwan, ang client - 95%. Bukod dito, kahit na ang mobile platform ay gumagamit ng parehong C++ code bilang ang "malaki" na isa, kahit na ang porsyento ng pag-iisa doon ay medyo mas mababa.
Tulad ng karamihan sa mga user ng C++, hindi namin inaangkin na ginagamit namin ang 100% ng mga kakayahan ng wika at mga aklatan nito. Kaya, halos hindi kami gumagamit ng Boost, at isa sa mga feature ng wika ay ang dynamic na uri ng casting. Kasabay nito, aktibong ginagamit namin ang:
STL (partikular ang mga string, container at algorithm)
maramihang mana, kasama. maramihang pagpapatupad na mana
mga template
pagbubukod
smart pointer (custom na pagpapatupad)
Sa pamamagitan ng paggamit ng maramihang pamana ng mga interface (ganap na abstract na mga klase), nagiging posible ang isang component model, na tatalakayin sa ibaba.
Piraso
Upang matiyak ang modularity, ang lahat ng functionality ay nahahati sa mga bahagi, na mga dynamic na library (*.dll para sa Windows, *.so para sa Linux). Mayroong higit sa isang daan at limampung bahagi sa kabuuan; narito ang mga paglalarawan ng ilan sa mga ito:
backend
Naglalaman ng platform metadata engine
accnt
Mga bagay na ginagamit ng mga developer ng application upang bumuo ng mga talaan ng accounting (mga chart ng mga account at mga rehistro ng accounting)
bsl
Naka-embed na engine ng pagpapatupad ng wika
nuke
Custom na pagpapatupad ng memory allocator
dbeng8
Engine ng database ng file. Isang simpleng file server database engine batay sa ISAM, na kinabibilangan din ng isang simpleng SQL processor
wbase
Naglalaman ng mga batayang klase at pag-andar para sa pagpapatupad ng interface ng gumagamit ng Windows - mga klase sa window, pag-access sa GDI, atbp.
Ang paghahati sa maraming bahagi ay kapaki-pakinabang mula sa ilang mga punto ng view:
Ang paghihiwalay ay nagpo-promote ng mas mahusay na disenyo, sa partikular na mas mahusay na paghihiwalay ng code
Mula sa isang hanay ng mga bahagi maaari mong flexible na bumuo ng iba't ibang mga opsyon sa paghahatid:
Halimbawa, ang pag-install ng thin client ay maglalaman ng wbase, ngunit hindi magkakaroon ng backend
ngunit sa wbase server, sa kabaligtaran, hindi ito magiging
ang parehong mga pagpipilian ay siyempre naglalaman ng nuke at bsl
Ang lahat ng mga sangkap na kinakailangan para sa opsyon sa paglulunsad na ito ay na-load kapag nagsimula ang programa. Ito, sa partikular, ay kinakailangan para sa pagpaparehistro ng mga klase ng SCOM, na tatalakayin sa ibaba.
SCOM
Para sa decomposition sa mas mababang antas, ginagamit ang SCOM system, isang library na katulad ng ideolohiya sa ATL. Para sa mga hindi pa nagtrabaho sa ATL, maikli naming inilista ang mga pangunahing kakayahan at tampok.
Para sa isang espesyal na idinisenyong klase ng SCOM:
Nagbibigay ng mga pamamaraan ng pabrika na nagbibigay-daan sa iyong lumikha ng isang klase mula sa isa pang bahagi na alam lamang ang pangalan nito (nang hindi inilalantad ang pagpapatupad)
Nagbibigay ng reference-counting smart pointer infrastructure. Ang buhay ng klase ng SCOM ay hindi kailangang manu-manong subaybayan
Binibigyang-daan kang malaman kung ang isang bagay ay nagpapatupad ng isang partikular na interface at awtomatikong nagko-convert ng isang pointer sa bagay sa isang pointer sa interface
Gumawa ng object ng serbisyo na laging naa-access sa pamamagitan ng get_service method, atbp.
Halimbawa, maaari mong ilarawan ang isang klase para sa pagbabasa ng JSON (halimbawa, JSONStreamReader) sa bahagi ng json.dll.
Maaaring malikha ang mga klase at instance mula sa iba pang mga bahagi; kailangan nilang mairehistro sa makina ng SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Ilalarawan ng macro na ito ang isang espesyal na klase ng static recorder, ang constructor nito ay tatawagin kapag na-load ang component sa memorya.
Pagkatapos nito, maaari kang lumikha ng isang instance nito sa isa pang bahagi:
Upang suportahan ang mga serbisyo, nag-aalok ang SCOM ng karagdagang, medyo kumplikadong imprastraktura. Ang sentro nito ay ang konsepto ng isang proseso ng SCOM, na nagsisilbing lalagyan para sa pagpapatakbo ng mga serbisyo (i.e., gumaganap sa papel ng Service Locator), at naglalaman din ng isang binding sa mga lokal na mapagkukunan. Ang proseso ng SCOM ay nakatali sa OS thread. Salamat dito, sa loob ng application maaari kang makatanggap ng mga serbisyong tulad nito:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Bukod dito, sa pamamagitan ng paglipat ng mga prosesong lohikal (SCOM) na nakatali sa isang thread, maaari kang makakuha ng mga application na halos independyente mula sa punto ng view ng espasyo ng impormasyon, na tumatakbo sa loob ng parehong thread. Ito ay kung paano gumagana ang aming thin client sa isang database ng file - sa loob ng isang proseso ng OS mayroong dalawang proseso ng SCOM, ang isa ay nauugnay sa kliyente, at ang pangalawa sa server. Ang diskarte na ito ay nagbibigay-daan sa amin na pag-isahin ang pagsulat ng code na gagana pareho sa lokal na database ng file at sa "tunay" na bersyon ng client-server. Ang presyo para sa gayong pagkakapareho ay nasa itaas, ngunit ang pagsasanay ay nagpapakita na ito ay katumbas ng halaga.
Batay sa modelo ng bahagi ng SCOM, ang parehong lohika ng negosyo at ang bahagi ng interface ng 1C: Enterprise ay ipinatupad.
User interface
Sa pamamagitan ng paraan, tungkol sa mga interface. Hindi kami gumagamit ng karaniwang mga kontrol sa Windows; ang aming mga kontrol ay direktang ipinapatupad sa Windows API. Para sa bersyon ng Linux, isang layer ang ginawa na gumagana sa pamamagitan ng wxWidgets library.
Ang library ng mga kontrol ay hindi nakadepende sa iba pang bahagi ng 1C:Enterprise at ginagamit namin sa ilang iba pang maliliit na panloob na kagamitan.
Sa paglipas ng mga taon ng pag-unlad ng 1C:Enterprise, ang hitsura ng mga kontrol ay nagbago, ngunit ang isang seryosong pagbabago sa mga prinsipyo ay nangyari nang isang beses lamang, noong 2009, sa paglabas ng bersyon 8.2 at ang pagdating ng "pinamamahalaang mga form". Bilang karagdagan sa pagbabago ng hitsura, ang prinsipyo ng layout ng form ay sa panimula ay nagbago - nagkaroon ng pagtanggi sa pixel-by-pixel na pagpoposisyon ng mga elemento na pabor sa daloy-layout ng mga elemento. Bilang karagdagan, sa bagong modelo, ang mga kontrol ay hindi direktang gumagana sa mga bagay ng domain, ngunit sa mga espesyal na DTO (Mga Bagay sa Paglilipat ng Data).
Ang mga pagbabagong ito ay naging posible upang lumikha ng isang 1C:Enterprise web client na ginagaya ang C++ na lohika ng mga kontrol ng JavaScript. Sinusubukan naming mapanatili ang functional equivalence sa pagitan ng thin at web client. Sa mga kaso kung saan hindi ito posible, halimbawa dahil sa mga limitasyon ng JavaScript API na magagamit (halimbawa, ang kakayahang magtrabaho kasama ang mga file ay napakalimitado), madalas naming ipinapatupad ang kinakailangang paggana gamit ang mga extension ng browser na nakasulat sa C++. Kasalukuyan naming sinusuportahan ang Internet Explorer at Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows at Linux) at Safari (MacOS).
Bilang karagdagan, ang teknolohiya ng mga pinamamahalaang form ay ginagamit upang lumikha ng isang interface para sa mga mobile application sa 1C platform. Sa mga mobile device, ang pag-render ng mga kontrol ay ipinapatupad gamit ang mga teknolohiyang native sa operating system, ngunit para sa form layout logic at interface na tugon, ang parehong code ay ginagamit tulad ng sa "malaking" 1C:Enterprise platform.
1C interface sa Linux OS
1C interface sa isang mobile device
1C interface sa iba pang mga platform 1C interface sa Windows OS
Interface 1C - web client
open source
Bagama't hindi kami gumagamit ng mga karaniwang aklatan para sa mga developer ng C++ sa ilalim ng Windows (MFC, mga kontrol mula sa WinAPI), hindi namin isinusulat ang lahat ng mga bahagi sa aming sarili. Nabanggit na ang library wxWidgets, at ginagamit din namin ang:
Ang listahan ay nagpapatuloy.
Bukod pa rito, gumagamit kami ng lubos na binagong bersyon Pagsubok sa Google ΠΈ Google Mock kapag bumubuo ng mga pagsubok sa yunit.
Ang mga aklatan ay nangangailangan ng adaptasyon upang maging tugma sa modelo ng organisasyong bahagi ng SCOM.
Ang paglaganap ng 1C ay gumagawa ng platform na isang mahusay na pagsubok ng lakas para sa mga aklatan na ginagamit dito. Ang iba't ibang mga user at mga sitwasyon ay mabilis na nagpapakita ng mga error sa kahit na ang pinaka-bihirang ginagamit na mga lugar ng code. Itinutuwid namin ang mga ito sa aming sarili at sinusubukang ibalik ang mga ito sa mga may-akda ng aklatan. Ang karanasan ng pakikipag-ugnayan ay lumalabas na ibang-iba.
Mga Nag-develop magkulot ΠΈ libetpan mabilis na tumugon sa mga pull-request, ngunit ang patch, halimbawa, sa OpenSSL Hindi namin nagawang ibalik ito.
Konklusyon
Sa artikulo ay hinawakan namin ang ilang pangunahing aspeto ng pagbuo ng 1C: Enterprise platform. Sa limitadong saklaw ng artikulo, hinawakan lamang namin ang ilang mga kawili-wiling, sa aming opinyon, mga aspeto.
Ang isang pangkalahatang paglalarawan ng iba't ibang mga mekanismo ng platform ay matatagpuan dito.
Anong mga paksa ang magiging kawili-wili sa iyo sa mga artikulo sa hinaharap?
Paano ipinapatupad ang 1C mobile platform?
Paglalarawan ng panloob na istraktura ng web client?
O baka interesado ka sa proseso ng pagpili ng mga feature para sa mga bagong release, pagbuo at pagsubok?