Haai Habr!
In hierdie artikel begin ons 'n storie oor hoe dit binne werk en watter tegnologieë in die ontwikkeling daarvan gebruik word.
Hoekom dink ons is dit interessant? Eerstens, omdat die 1C:Enterprise 8-platform 'n groot (meer as 10 miljoen reëls kode) toepassing is wat geskryf is in C++ (kliënt, bediener, ens.), JavaScript (webkliënt), en, meer onlangs, En . Groot projekte is interessant, al is dit net vanweë hul omvang, want kwessies wat onsigbaar is in 'n klein kodebasis, in sulke projekte, styg tot hul volle hoogte. Tweedens, 1C:Enterprise is 'n gerepliseerde, "boks" produk, en daar is baie min artikels oor sulke ontwikkelings op Habré. En dit is altyd interessant om uit te vind hoe hulle in ander spanne en firmas leef.
So kom ons begin. In hierdie artikel sal ons 'n oorsig gee van sommige van die tegnologieë wat in die platform gebruik word, die landskap uiteensit sonder om diep in die implementering te duik. Inderdaad, vir baie meganismes sal 'n gedetailleerde storie op 'n aparte artikel trek, en vir sommige - op 'n hele boek!
Om mee te begin, is dit die moeite werd om oor die basiese dinge te besluit - wat is die 1C:Enterprise-platform en uit watter komponente dit bestaan. Die antwoord op hierdie vraag is nie so eenvoudig nie, want die term "Platform" (vir bondigheid sal ons dit so noem) word verstaan as 'n hulpmiddel vir die ontwikkeling van besigheidstoepassings, en 'n uitvoeringsomgewing, en administrasiehulpmiddels. Voorwaardelik kan die volgende komponente onderskei word:
- bedienergroepering
- "dun" kliënt wat in staat is om aan die bediener te koppel via http en sy eie binêre protokol
- kliënt om in 'n tweevlak-argitektuur te werk met 'n databasis wat op 'n hardeskyf of netwerkgids geleë is
- webkliënt
- toepassingsbediener administrasie gereedskap
- ontwikkelingsomgewing (bekend as Configurator)
- uitvoeringsomgewing vir iOS, Android en Windows Phone (mobiele platform 1C)
Al hierdie dele, met die uitsondering van die webkliënt, is in C++ geskryf. Daarbenewens is daar die onlangs aangekondigde , geskryf in Java.
Inheemse toepassings
C++03 word gebruik om inheemse toepassings te ontwikkel. Onder Windows word Microsoft Visual C++ 12 ('n profiel versoenbaar met Windows XP) as 'n samesteller gebruik, terwyl onder Linux en Android gcc 4.8 gebruik word, en vir iOS, clang 5.0. Die standaard biblioteek wat gebruik word, is dieselfde vir alle bedryfstelsels en samestellers - STLPort. Hierdie oplossing verminder die moontlikheid van foute spesifiek vir die implementering van die STL. Ons beplan tans om oor te skakel na die STL-implementering wat met CLang voorsien word, aangesien STLPort opgeskort is en nie versoenbaar is met gcc se geaktiveerde C++11-ondersteuningsmodus nie.
Die kodebasis van die bediener is 99% algemeen, die kliënt - 95% persent. Boonop gebruik selfs die mobiele platform dieselfde C++-kode as die "groot" een, hoewel die persentasie van eenwording ietwat laer daar is.
Soos die meeste C++-gebruikers, beweer ons nie dat ons 100% van die taal en sy biblioteke gebruik nie. So, ons gebruik feitlik nie Boost nie, en uit die moontlikhede van die taal - dinamiese tipe casting. Deur dit te doen, gebruik ons aktief:
- STL (spesifiek stringe, houers en algoritmes)
- meervoudige erfenis, inkl. meervoudige implementering oorerwing
- templates
- uitsonderings
- slim wysers (inheemse implementering)
Deur die gebruik van meervoudige oorerwing van koppelvlakke (heeltemal abstrakte klasse), word die komponentmodel moontlik, wat hieronder bespreek sal word.
Komponente
Om modulariteit te verseker, word alle funksionaliteit opgedeel in komponente wat dinamiese biblioteke is (*.dll onder Windows, *.so - onder Linux). Daar is meer as een en 'n half honderd komponente in totaal, ons sal beskrywings van sommige van hulle gee:
backend
Bevat die "enjin" van die platform metadata
aknt
Voorwerpe wat toepassingsontwikkelaars gebruik om rekeningkunde te bou (rekeningkaarte en rekeningkundige registers)
bsl
Ingebedde taaluitvoerenjin
nuke
Eie implementering van die geheuetoewyser
dbeng8
Lêerbasis-enjin. 'n Eenvoudige ISAM-gebaseerde lêerbediener-databasisenjin wat ook 'n eenvoudige SQL-verwerker insluit
wbasis
Bevat basisklasse en funksies vir die implementering van die Windows-gebruikerskoppelvlak—vensterklasse, GDI-toegang, ensovoorts.
Om in baie komponente te verdeel is nuttig op verskeie maniere:
- Skeiding bevorder beter ontwerp, veral beter kode-isolasie
- Uit 'n stel komponente kan u verskillende afleweringsopsies buigsaam saamstel:
- Byvoorbeeld, 'n dunkliëntinstallasie sal wbase bevat, maar geen backend nie
- en op die wbase-bediener, inteendeel, dit sal nie
- beide sal natuurlik nuke en bsl bevat
Al die komponente wat vir hierdie bekendstellingopsie benodig word, word gelaai wanneer die program begin. Dit is veral nodig vir die registrasie van SCOM-klasse, wat hieronder bespreek sal word.
SCOM
Vir ontbinding op 'n laer vlak word die SCOM-stelsel gebruik - 'n biblioteek soortgelyk in ideologie aan ATL. Vir diegene wat nie met ATL gewerk het nie, lys kortliks die hoofkenmerke en kenmerke.
Vir 'n pasgemaakte SCOM-klas:
- Verskaf fabrieksmetodes wat jou toelaat om 'n klas van 'n ander komponent te skep met net die naam daarvan (sonder om die implementering te openbaar)
- Verskaf 'n verwysingsgetelde slimwyser-infrastruktuur. Die leeftyd van 'n SCOM-klas hoef nie met die hand gemonitor te word nie
- Laat jou toe om uit te vind of 'n voorwerp 'n spesifieke koppelvlak implementeer en stuur die wyser outomaties na die voorwerp na die wyser na die koppelvlak
- Skep 'n diensobjek wat altyd beskikbaar is via die get_service metode, ens.
Byvoorbeeld, jy kan 'n klas definieer vir die lees van JSON (byvoorbeeld, JSONStreamReader) in die json.dll-komponent.
Klasse, gevalle kan van ander komponente geskep word, u moet in die SCOM-masjien registreer:
SCOM_CLASS_ENTRY(JSONStreamReader)
Hierdie makro sal 'n spesiale statiese registrateurklas beskryf wie se konstruktor geroep sal word wanneer die komponent in die geheue gelaai word.
Daarna kan u 'n instansie daarvan in 'n ander komponent skep:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Om dienste te ondersteun, bied SCOM 'n bykomende, taamlik komplekse infrastruktuur. Sentraal daarin is die konsep van 'n SCOM-proses, wat dien as 'n houer vir die bestuur van dienste (dit wil sê, dien as 'n diensopspoorder), en ook 'n binding aan lokaliseerbare hulpbronne bevat. 'n SCOM-proses is aan 'n OS-draad gebind. Danksy hierdie, binne die toepassing, kan u dienste soos hierdie ontvang:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Verder, deur logiese (SCOM) prosesse wat aan 'n draad gekoppel is, te skakel, kan jy toepassings kry wat prakties onafhanklik is vanuit die oogpunt van die inligtingspasie en binne dieselfde draad loop. Dit is hoe ons dun kliënt met die lêerbasis werk - binne een OS-proses is daar twee SCOM-prosesse, een is aan die kliënt gekoppel, en die tweede aan die bediener. Hierdie benadering laat jou toe om die skryf van kode te verenig wat beide op 'n plaaslike lêerbasis en in 'n "regte" kliënt-bediener weergawe sal werk. Die prys vir sulke eenvormigheid is bokoste, maar die praktyk wys dat dit die moeite werd is.
Gebaseer op die SCOM-komponentmodel, word beide die besigheidslogika en die koppelvlakdeel van 1C: Enterprise geïmplementeer.
Gebruikerskoppelvlak
Terloops, oor koppelvlakke. Ons gebruik nie standaard Windows-kontroles nie, ons kontroles word direk op die Windows API geïmplementeer. Vir die Linux-weergawe is 'n laag gemaak wat deur die wxWidgets-biblioteek werk.
Die biblioteek van kontroles is nie afhanklik van ander dele van 1C:Enterprise nie en word deur ons in verskeie ander klein interne nutsprogramme gebruik.
Oor die jare van ontwikkeling van 1C:Enterprise het die voorkoms van kontroles verander, maar 'n ernstige verandering in beginsels het slegs een keer plaasgevind, in 2009, met die vrystelling van weergawe 8.2 en die koms van "bestuurde vorms". Benewens die verandering van die voorkoms, het die beginsel van vormuitleg fundamenteel verander - daar was 'n verwerping van pixel-vir-pixel-posisionering van elemente ten gunste van die vloei-uitleg van elemente. Daarbenewens werk kontroles in die nuwe model nie direk met domeinobjekte nie, maar met spesiale DTO's ().
Hierdie veranderinge het dit moontlik gemaak om 'n 1C:Enterprise-webkliënt te skep wat die C++-beheerlogika in JavaScript herhaal. Ons probeer om funksionele ekwivalensie tussen dun en webkliënte te handhaaf. Wanneer dit nie moontlik is nie, byvoorbeeld as gevolg van beperkings wat beskikbaar is vanaf die JavaScript API (byvoorbeeld, die vermoë om met lêers te werk is baie beperk), implementeer ons dikwels die verlangde funksionaliteit deur blaaieruitbreidings wat in C ++ geskryf is. Ons ondersteun tans Internet Explorer en Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows en Linux) en Safari (MacOS).
Daarbenewens word die tegnologie van bestuurde vorms gebruik om die koppelvlak van mobiele toepassings op die 1C-platform te skep. Op mobiele toestelle word die tekening van kontroles geïmplementeer deur gebruik te maak van tegnologieë wat inheems aan die bedryfstelsel is, maar dieselfde kode word gebruik vir die vormuitleglogika en koppelvlakreaksie as in die "groot" 1C:Enterprise-platform.
1C-koppelvlak op Linux OS
1C-koppelvlak op 'n mobiele toestel
1C-koppelvlak op ander platforms
1C koppelvlak op Windows OS
Interface 1C - webkliënt
Oop bron
Alhoewel ons nie standaardbiblioteke vir C++-ontwikkelaars onder Windows (MFC, kontroles van WinAPI) gebruik nie, skryf ons nie al die komponente self nie. Die biblioteek is reeds genoem. en ons gebruik ook:
- om met HTTP en FTP te werk.
- om met kriptografie te werk en TLS-verbindings te vestig
- vir XML-ontleding
- om met posprotokolle te werk (POP3, SMTP, IMAP)
- om e-posboodskappe te ontleed
- vir die stoor van gebruikerslogboeke
- vir internasionalisering
Die lys kan steeds voortgesit word.
Daarbenewens gebruik ons 'n sterk aangepaste weergawe и wanneer eenheidstoetse ontwikkel word.
Die biblioteke het aanpassing vereis om versoenbaar te wees met die SCOM-komponent-organisasiemodel.
Die voorkoms van 1C maak die platform 'n uitstekende sterktetoets vir die biblioteke wat daarin gebruik word. 'n Verskeidenheid gebruikers en skrifte vind vinnig foute in selfs die mees selde gebruikte dele van die kode. Ons maak dit by die huis reg en probeer om dit aan die skrywers van die biblioteke terug te gee. Die interaksie-ervaring is baie anders.
Developers и reageer vinnig op 'n trek-versoek, maar die pleister, byvoorbeeld, in ons hoef dit nooit terug te gee nie.
Gevolgtrekking
In die artikel het ons verskeie hoofaspekte van die ontwikkeling van die 1C: Enterprise-platform aangeraak. In die beperkte volume van die artikel het ons slegs enkele interessante, na ons mening, aspekte aangeraak.
'n Algemene beskrywing van die verskillende meganismes van die platform kan bekyk word .
Watter onderwerpe sal vir jou van belang wees in toekomstige artikels?
Hoe word die 1C mobiele platform geïmplementeer?
Beskrywing van die interne toestel van die webkliënt?
Of stel jy dalk belang in die proses van kenmerkkeuse vir nuwe vrystellings, ontwikkeling en toetsing?
Skryf in die kommentaar!
Bron: will.com