Hej Habr!
I denne artikel vil vi begynde historien om, hvordan det fungerer indeni og hvilke teknologier der bruges i udviklingen.
Hvorfor synes vi, det er interessant? For det første fordi 1C:Enterprise 8-platformen er en stor (mere end 10 millioner linjer kode) applikation i C++ (klient, server osv.), JavaScript (webklient) og, for nylig, Og . Store projekter kan være interessante i det mindste på grund af deres omfang, fordi problemer, der er usynlige i en lille kodebase, opstår med fuld kraft i sådanne projekter. For det andet er "1C:Enterprise" et replikerbart, "indpakket" produkt, og der er meget få artikler om sådanne udviklinger på Habré. Det er også altid interessant at vide, hvordan livet er i andre teams og virksomheder.
Så lad os komme i gang. I denne artikel vil vi give et overblik over nogle af de teknologier, der bruges i platformen og skitsere landskabet, uden at dykke dybt ned i implementeringen. For mange mekanismer ville en detaljeret historie faktisk kræve en separat artikel, og for nogle en hel bog!
Til at begynde med er det værd at tage stilling til de grundlæggende ting - hvad 1C:Enterprise platformen er, og hvilke komponenter den består af. Svaret på dette spørgsmål er ikke så enkelt, fordi udtrykket "Platform" (for kortheds skyld vil vi kalde det på den måde) refererer til et middel til at udvikle forretningsapplikationer, et runtime-miljø og administrationsværktøjer. Følgende komponenter kan groft skelnes:
- serverklynge
- "tynd" klient, der er i stand til at oprette forbindelse til serveren via http og sin egen binære protokol
- klient til at arbejde i en to-lags arkitektur med en database placeret på en harddisk eller netværksmappe
- webklient
- applikationsserver administrationsværktøjer
- udviklingsmiljø (kendt som Configurator)
- runtime miljø til iOS, Android og Windows Phone (mobilplatform 1C)
Alle disse dele, med undtagelse af webklienten, er skrevet i C++. Derudover er der den nyligt annoncerede , skrevet i Java.
Native apps
C++03 bruges til at udvikle native applikationer. Til Windows bruges Microsoft Visual C++ 12 (en profil, der er kompatibel med Windows XP) som compiler, og til Linux og Android - gcc 4.8, til iOS - clang 5.0. Det anvendte standardbibliotek er det samme for alle operativsystemer og compilere - STLPort. Denne løsning reducerer sandsynligheden for STL implementeringsspecifikke fejl. Vi planlægger i øjeblikket at migrere til STL-implementeringen, der blev leveret med CLang, da STLPort er udgået og er inkompatibel med gccs C++11-aktiverede tilstand.
Serverens kodebase er 99% almindelig, klientens - 95%. Desuden bruger selv den mobile platform den samme C++-kode som den "store", selvom procentdelen af forening der er noget lavere.
Som de fleste C++-brugere hævder vi ikke at bruge 100 % af sprogets og dets bibliotekers muligheder. Så vi bruger praktisk talt ikke Boost, og en af sprogfunktionerne er dynamisk type casting. Samtidig bruger vi aktivt:
- STL (specifikt strenge, containere og algoritmer)
- multipel arv, inkl. multipel implementeringsarv
- skabeloner
- undtagelser
- smarte pointers (tilpasset implementering)
Ved at bruge multipel nedarvning af grænseflader (helt abstrakte klasser) bliver en komponentmodel mulig, som vil blive diskuteret nedenfor.
Komponenter
For at sikre modularitet er al funktionalitet opdelt i komponenter, som er dynamiske biblioteker (*.dll til Windows, *.so til Linux). Der er mere end hundrede og halvtreds komponenter i alt; her er beskrivelser af nogle af dem:
backend
Indeholder platformens metadatamotor
acnt
Objekter, som applikationsudviklere bruger til at opbygge regnskabsposter (kontoplaner og regnskabsregistre)
BSL
Indlejret sprogudførelsesmotor
nuke
Brugerdefineret implementering af memory allocator
dbeng8
Fildatabasemotor. En simpel filserverdatabasemotor baseret på ISAM, som også inkluderer en simpel SQL-processor
wbase
Indeholder basisklasserne og funktionerne til implementering af Windows-brugergrænsefladen - vinduesklasser, GDI-adgang mv.
At opdele i flere komponenter er nyttigt fra flere synspunkter:
- Adskillelse fremmer bedre design, især bedre kodeisolering
- Fra et sæt komponenter kan du fleksibelt sammensætte forskellige leveringsmuligheder:
- For eksempel vil en tynd klientinstallation indeholde wbase, men vil ikke have backend
- men på wbase-serveren bliver det tværtimod ikke
- begge muligheder vil selvfølgelig indeholde nuke og bsl
Alle komponenter, der kræves til denne startmulighed, indlæses, når programmet starter. Dette er især nødvendigt for at registrere SCOM-klasser, som vil blive diskuteret nedenfor.
SCOM
Til nedbrydning på et lavere niveau anvendes SCOM-systemet, et bibliotek, der ideologisk ligner ATL. For dem, der ikke har arbejdet med ATL, lister vi kort de vigtigste muligheder og funktioner.
For en specialdesignet SCOM-klasse:
- Giver fabriksmetoder, der giver dig mulighed for at oprette en klasse fra en anden komponent, der kun kender dens navn (uden at afsløre implementeringen)
- Giver en reference-tæller smart pointer-infrastruktur. SCOM-klassens levetid behøver ikke overvåges manuelt
- Giver dig mulighed for at finde ud af, om et objekt implementerer en specifik grænseflade og automatisk konvertere en markør til objektet til en markør til grænsefladen
- Opret et serviceobjekt, der altid er tilgængeligt via get_service metoden osv.
For eksempel kan du beskrive en klasse til læsning af JSON (f.eks. JSONStreamReader) i json.dll-komponenten.
Klasser og instanser kan oprettes fra andre komponenter; de skal registreres i SCOM-maskinen:
SCOM_CLASS_ENTRY(JSONStreamReader)
Denne makro vil beskrive en speciel statisk optagerklasse, hvis konstruktør vil blive kaldt, når komponenten indlæses i hukommelsen.
Herefter kan du oprette en forekomst af det i en anden komponent:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
For at understøtte tjenester tilbyder SCOM en ekstra, ret kompleks infrastruktur. Centralt i det er konceptet med en SCOM-proces, der fungerer som en beholder til at køre tjenester (dvs. spiller rollen som Service Locator), og som også indeholder en binding til lokaliserede ressourcer. SCOM-processen er knyttet til OS-tråden. Takket være dette kan du i applikationen modtage tjenester som dette:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Desuden, ved at skifte logiske (SCOM) processer knyttet til en tråd, kan du få applikationer, der er praktisk talt uafhængige fra synspunktet af informationsrummet, kørende inden for den samme tråd. Sådan fungerer vores tynde klient med en fildatabase - inde i en OS-proces er der to SCOM-processer, en tilknyttet klienten og den anden med serveren. Denne tilgang giver os mulighed for at forene skrivningen af kode, der fungerer både på den lokale fildatabase og i den "rigtige" klient-serverversion. Prisen for en sådan ensartethed er overhead, men praksis viser, at det er det værd.
Baseret på SCOM-komponentmodellen implementeres både forretningslogikken og interfacedelen af 1C: Enterprise.
brugergrænseflade
I øvrigt om grænseflader. Vi bruger ikke standard Windows-kontroller; vores kontroller implementeres direkte på Windows API. Til Linux-versionen er der lavet et lag, der fungerer gennem wxWidgets-biblioteket.
Biblioteket af kontrolelementer afhænger ikke af andre dele af 1C:Enterprise og bruges af os i flere andre små interne hjælpeprogrammer.
I løbet af årene med udvikling af 1C:Enterprise har udseendet af kontroller ændret sig, men en alvorlig ændring i principper fandt sted kun én gang, i 2009, med udgivelsen af version 8.2 og fremkomsten af "administrerede formularer". Ud over at ændre udseendet har princippet om formlayout ændret sig fundamentalt - der har været en afvisning af pixel-for-pixel placering af elementer til fordel for flow-layout af elementer. Derudover fungerer kontroller i den nye model ikke direkte med domæneobjekter, men med specielle DTO'er ().
Disse ændringer gjorde det muligt at oprette en 1C:Enterprise-webklient, der replikerer C++-logikken i JavaScript-kontroller. Vi forsøger at opretholde funktionel ækvivalens mellem tynde og webklienter. I tilfælde hvor dette ikke er muligt, for eksempel på grund af begrænsninger af den tilgængelige JavaScript API (f.eks. er muligheden for at arbejde med filer meget begrænset), implementerer vi ofte den nødvendige funktionalitet ved hjælp af browserudvidelser skrevet i C++. Vi understøtter i øjeblikket Internet Explorer og Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows og Linux) og Safari (MacOS).
Derudover bruges managed forms-teknologi til at skabe en grænseflade til mobile applikationer på 1C-platformen. På mobile enheder implementeres gengivelsen af kontroller ved hjælp af teknologier, der er hjemmehørende i operativsystemet, men til formlayoutlogikken og grænsefladesvaret bruges den samme kode som i den "store" 1C:Enterprise-platform.
1C-grænseflade på Linux OS
1C interface på en mobil enhed
1C interface på andre platforme
1C-grænseflade på Windows OS
Interface 1C - webklient
Open source
Selvom vi ikke bruger standardbiblioteker til C++ udviklere under Windows (MFC, kontroller fra WinAPI), skriver vi ikke alle komponenter selv. Biblioteket er allerede nævnt , og vi bruger også:
- til at arbejde med HTTP og FTP.
- til arbejde med kryptografi og etablering af TLS-forbindelser
- til XML-parsing
- til arbejde med postprotokoller (POP3, SMTP, IMAP)
- at parse e-mail-beskeder
- til lagring af brugerlogfiler
- til internationalisering
Listen fortsætter.
Derudover bruger vi en meget modificeret version и ved udvikling af enhedstests.
Bibliotekerne krævede tilpasning for at være kompatible med SCOM-komponentorganisationsmodellen.
Udbredelsen af 1C gør platformen til en fremragende test af styrke for de biblioteker, der bruges i den. En række brugere og scenarier afslører hurtigt fejl i selv de mest sjældent brugte kodeområder. Vi retter dem selv og forsøger at give dem tilbage til bibliotekets forfattere. Oplevelsen af interaktion viser sig at være meget anderledes.
Udviklere и reagere hurtigt på pull-anmodninger, men patchen f.eks Vi formåede aldrig at give det tilbage.
Konklusion
I artiklen kom vi ind på flere hovedaspekter af udviklingen af 1C: Enterprise platformen. I artiklens begrænsede omfang berørte vi kun nogle interessante, efter vores mening, aspekter.
En generel beskrivelse af de forskellige platformsmekanismer kan findes .
Hvilke emner ville være interessante for dig i fremtidige artikler?
Hvordan implementeres 1C-mobilplatformen?
Beskrivelse af webklientens interne struktur?
Eller måske er du interesseret i processen med at vælge funktioner til nye udgivelser, udvikle og teste?
Skriv i kommentarerne!
Kilde: www.habr.com