Hei Habr!
Tässä artikkelissa aloitamme tarinan siitä, kuinka se toimii sisällä ja mitä tekniikoita sen kehittämisessä käytetään.
Miksi tämä on mielestämme mielenkiintoista? Ensinnäkin, koska 1C:Enterprise 8 -alusta on suuri (yli 10 miljoonaa koodiriviä) sovellus C++:ssa (asiakas, palvelin jne.), JavaScriptissä (verkkoasiakas) ja viime aikoina Ja . Suuret projektit voivat olla kiinnostavia ainakin mittakaavansa takia, sillä pienessä koodikannassa näkymättömät asiat nousevat sellaisissa projekteissa esiin täysillä. Toiseksi "1C:Enterprise" on replikoitava, "laatikollinen" tuote, ja Habréssa on hyvin vähän artikkeleita tällaisesta kehityksestä. On myös aina mielenkiintoista tietää, millaista elämä on muissa tiimeissä ja yrityksissä.
Joten aloitetaan. Tässä artikkelissa annamme yleiskatsauksen joistakin alustassa käytetyistä teknologioista ja hahmottelemme maisemaa sukeltamatta syvällisesti toteutukseen. Todellakin, monille mekanismeille yksityiskohtainen tarina vaatisi erillisen artikkelin ja joillekin koko kirjan!
Aluksi kannattaa päättää perusasioista - mikä 1C:Enterprise-alusta on ja mistä komponenteista se koostuu. Vastaus tähän kysymykseen ei ole niin yksinkertainen, koska termi "Platform" (lyhytyyden vuoksi kutsumme sitä niin) viittaa keinoon kehittää liiketoimintasovelluksia, ajonaikaista ympäristöä ja hallintatyökaluja. Seuraavat komponentit voidaan erottaa karkeasti toisistaan:
- palvelinklusteri
- "ohut" asiakas, joka pystyy muodostamaan yhteyden palvelimeen http:n ja oman binaariprotokollansa kautta
- asiakas työskentelyyn kaksitasoisessa arkkitehtuurissa, jossa tietokanta sijaitsee kiintolevyllä tai verkkokansiossa
- web-asiakas
- sovelluspalvelimen hallintatyökalut
- kehitysympäristö (tunnetaan nimellä Configurator)
- ajonaikainen ympäristö iOS:lle, Androidille ja Windows Phonelle (mobiilialusta 1C)
Kaikki nämä osat, paitsi web-asiakas, on kirjoitettu C++:lla. Lisäksi on äskettäin julkistettu , kirjoitettu Java-kielellä.
Alkuperäiset sovellukset
C++03:a käytetään natiivisovellusten kehittämiseen. Windowsissa kääntäjänä käytetään Microsoft Visual C++ 12:ta (Windows XP:n kanssa yhteensopiva profiili) ja Linuxille ja Androidille - gcc 4.8, iOS:lle - clang 5.0. Käytetty vakiokirjasto on sama kaikille käyttöjärjestelmille ja kääntäjille - STLPort. Tämä ratkaisu vähentää STL-toteutuskohtaisten virheiden todennäköisyyttä. Suunnittelemme tällä hetkellä siirtymistä CLangin mukana toimitettuun STL-toteutukseen, koska STLPort on lopetettu eikä se ole yhteensopiva gcc:n C++11-yhteensopivan tilan kanssa.
Palvelimen koodikanta on 99 % yhteinen, asiakkaan - 95 %. Lisäksi jopa mobiilialusta käyttää samaa C++-koodia kuin "iso", vaikka siellä yhdistymisprosentti onkin hieman pienempi.
Kuten useimmat C++-käyttäjät, emme väitä käyttävämme 100 % kielen ja sen kirjastojen ominaisuuksista. Emme siis käytännössä käytä Boostia, ja yksi kieliominaisuuksista on dynaaminen tyyppi Casting. Samaan aikaan käytämme aktiivisesti:
- STL (erityisesti merkkijonot, säilöt ja algoritmit)
- moninkertainen perinnöllinen, sis. usean toteutuksen periytyminen
- malleja
- poikkeukset
- älykkäät osoittimet (muokattu toteutus)
Käyttämällä rajapintojen useaa periytymistä (täysin abstrakteja luokkia) tulee mahdolliseksi komponenttimalli, jota käsitellään alla.
Компоненты
Modulaarisuuden varmistamiseksi kaikki toiminnot on jaettu komponentteihin, jotka ovat dynaamisia kirjastoja (*.dll Windowsille, *.so Linuxille). Komponentteja on yhteensä yli sataviisikymmentä; tässä on kuvauksia joistakin niistä:
backend
Sisältää alustan metatietomoottorin
accnt
Objektit, joita sovelluskehittäjät käyttävät kirjanpitotietueiden (tilikaavioiden ja kirjanpitorekisterien) rakentamiseen
BSL
Sulautettu kielen suoritusmoottori
ydinase
Muistinvaraajan mukautettu toteutus
dbeng8
Tiedoston tietokantamoottori. Yksinkertainen ISAM-pohjainen tiedostopalvelintietokantamoottori, joka sisältää myös yksinkertaisen SQL-prosessorin
wbase
Sisältää perusluokat ja toiminnot Windows-käyttöliittymän toteuttamiseen - ikkunaluokat, GDI-käyttö jne.
Jakaminen useisiin komponentteihin on hyödyllistä useista näkökulmista:
- Erottaminen edistää parempaa suunnittelua, erityisesti parempaa koodin eristämistä
- Komponenttisarjasta voit koota joustavasti erilaisia toimitusvaihtoehtoja:
- Esimerkiksi Thin Client -asennus sisältää wbase-ohjelman, mutta sillä ei ole taustajärjestelmää
- mutta wbase-palvelimella sitä ei päinvastoin ole
- molemmat vaihtoehdot sisältävät tietysti nuken ja bsl:n
Kaikki tämän käynnistysvaihtoehdon edellyttämät komponentit ladataan ohjelman käynnistyessä. Tämä on tarpeen erityisesti SCOM-luokkien rekisteröimiseksi, joita käsitellään alla.
SCOM
Alemmalla tasolla tapahtuvaan hajotukseen käytetään SCOM-järjestelmää, ideologialtaan samanlaista kirjastoa kuin ATL. Niille, jotka eivät ole työskennelleet ATL:n kanssa, luettelemme lyhyesti tärkeimmät ominaisuudet ja ominaisuudet.
Erityisesti suunniteltu SCOM-luokka:
- Tarjoaa tehdasmenetelmiä, joiden avulla voit luoda luokan toisesta komponentista tietäen vain sen nimen (toteutusta paljastamatta)
- Tarjoaa viitteitä laskevan älykkään osoitininfrastruktuurin. SCOM-luokan käyttöikää ei tarvitse valvoa manuaalisesti
- Voit selvittää, toteuttaako objekti tietyn rajapinnan, ja muuntaa objektiin osoittavan osoittimen automaattisesti käyttöliittymän osoittimeksi
- Luo palveluobjekti, joka on aina käytettävissä get_service-menetelmällä jne.
Voit esimerkiksi kuvata luokan JSON-lukua varten (esimerkiksi JSONStreamReader) json.dll-komponentissa.
Luokkia ja ilmentymiä voidaan luoda muista komponenteista; ne on rekisteröitävä SCOM-koneeseen:
SCOM_CLASS_ENTRY(JSONStreamReader)
Tämä makro kuvaa erityistä staattista tallenninluokkaa, jonka rakentaja kutsutaan, kun komponentti ladataan muistiin.
Tämän jälkeen voit luoda siitä esiintymän toisessa komponentissa:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Palveluiden tukemiseksi SCOM tarjoaa ylimääräisen, melko monimutkaisen infrastruktuurin. Keskeinen siinä on SCOM-prosessin konsepti, joka toimii konttina palvelujen suorittamiselle (eli toimii Service Locatorin roolina) ja sisältää myös sidoksen lokalisoituihin resursseihin. SCOM-prosessi on sidottu käyttöjärjestelmän säikeeseen. Tämän ansiosta voit vastaanottaa sovelluksen sisällä tällaisia palveluita:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Lisäksi säikeeseen sidottuja loogisia (SCOM) prosesseja vaihtamalla saadaan tietoavaruuden kannalta käytännössä riippumattomia sovelluksia, jotka toimivat samassa säikeessä. Näin ohut asiakasohjelmamme toimii tiedostotietokannan kanssa - yhden käyttöjärjestelmäprosessin sisällä on kaksi SCOM-prosessia, joista toinen liittyy asiakkaaseen ja toinen palvelimeen. Tämän lähestymistavan avulla voimme yhdistää koodin kirjoittamisen, joka toimii sekä paikallisessa tiedostotietokannassa että "todellisessa" asiakas-palvelinversiossa. Tällaisen yhtenäisyyden hinta on yläpuolella, mutta käytäntö osoittaa, että se on sen arvoista.
SCOM-komponenttimalliin perustuen 1C: Enterprisen sekä liiketoimintalogiikka että käyttöliittymäosa on toteutettu.
Käyttöliittymä
Muuten, käyttöliittymistä. Emme käytä tavallisia Windows-säätimiä, vaan säätimet on toteutettu suoraan Windows API:ssa. Linux-versiolle on tehty taso, joka toimii wxWidgets-kirjaston kautta.
Ohjauskirjasto ei ole riippuvainen muista 1C:Enterprisen osista, ja käytämme sitä useissa muissa pienissä sisäisissä apuohjelmissa.
1C:Enterprisen kehitysvuosien aikana säätimien ulkonäkö on muuttunut, mutta vakava muutos periaatteissa tapahtui vain kerran, vuonna 2009, kun versio 8.2 julkaistiin ja "hallitut lomakkeet" tulivat. Ulkonäön muuttamisen lisäksi lomakeasettelun periaate on muuttunut perusteellisesti - elementtien pikselikohtaisesta sijoittelusta hylättiin elementtien virtausasettelu. Lisäksi uudessa mallissa ohjausobjektit eivät toimi suoraan toimialueobjektien kanssa, vaan erityisten DTO:iden ().
Nämä muutokset mahdollistivat 1C:Enterprise-verkkoasiakkaan luomisen, joka toistaa JavaScript-ohjaimien C++-logiikan. Pyrimme ylläpitämään toiminnallista vastaavuutta ohuiden ja verkkoasiakkaiden välillä. Tapauksissa, joissa tämä ei ole mahdollista, esimerkiksi saatavilla olevan JavaScript API:n rajoitusten vuoksi (esimerkiksi kyky työskennellä tiedostojen kanssa on hyvin rajallinen), toteutamme tarvittavat toiminnot usein C++:lla kirjoitetuilla selainlaajennuksilla. Tuemme tällä hetkellä Internet Exploreria ja Microsoft Edgeä (Windows), Google Chromea (Windows), Firefoxia (Windows ja Linux) ja Safaria (MacOS).
Lisäksi hallittujen lomakkeiden teknologiaa käytetään luomaan käyttöliittymä mobiilisovelluksille 1C-alustalle. Mobiililaitteissa säätimien renderöinti toteutetaan käyttämällä käyttöjärjestelmälle luontaisia teknologioita, mutta lomakkeen asettelulogiikassa ja käyttöliittymävasteessa käytetään samaa koodia kuin "suuressa" 1C:Enterprise-alustassa.
1C-käyttöliittymä Linux-käyttöjärjestelmässä
1C-liitäntä mobiililaitteessa
1C-käyttöliittymä muilla alustoilla
1C-käyttöliittymä Windows-käyttöjärjestelmässä
Käyttöliittymä 1C - verkkoasiakas
Avoin lähdekoodi
Vaikka emme käytä vakiokirjastoja C++-kehittäjille Windowsissa (MFC, ohjaukset WinAPI:sta), emme kirjoita kaikkia komponentteja itse. Kirjasto on jo mainittu ja käytämme myös:
- HTTP:n ja FTP:n kanssa työskentelemiseen.
- salauksen parissa työskentelemiseen ja TLS-yhteyksien luomiseen
- XML-jäsennystä varten
- sähköpostiprotokollien (POP3, SMTP, IMAP) kanssa työskentelemiseen
- jäsentää sähköpostiviestejä
- käyttäjälokien tallentamiseen
- kansainvälistymistä varten
Lista jatkuu.
Lisäksi käytämme erittäin muokattua versiota и yksikkötestejä kehitettäessä.
Kirjastot vaativat mukauttamista ollakseen yhteensopivia SCOM-komponenttiorganisaatiomallin kanssa.
1C:n yleisyys tekee alustasta erinomaisen vahvuustestin siinä käytetyille kirjastoille. Useat käyttäjät ja skenaariot paljastavat nopeasti virheet jopa harvemmin käytetyillä koodialueilla. Korjaamme ne itse ja yritämme palauttaa ne kirjaston tekijöille. Vuorovaikutuskokemus osoittautuu hyvin erilaiseksi.
Kehittäjät и Vastaa nopeasti vetopyyntöihin, mutta esimerkiksi korjaustiedosto sisään Emme koskaan onnistuneet antamaan sitä takaisin.
Johtopäätös
Artikkelissa käsittelimme useita 1C: Enterprise -alustan kehittämisen päänäkökohtia. Artikkelin rajoitetussa laajuudessa käsittelimme vain joitain mielenkiintoisia, mielestämme kiinnostavia näkökohtia.
Yleiskuvaus eri alustamekanismeista löytyy .
Mitkä aiheet kiinnostaisivat sinua tulevissa artikkeleissa?
Miten 1C-mobiilialusta toteutetaan?
Kuvaus web-asiakkaan sisäisestä rakenteesta?
Tai ehkä olet kiinnostunut uusien julkaisujen ominaisuuksien valinnasta, kehittämisestä ja testaamisesta?
Kirjoita kommentteihin!
Lähde: will.com