Hé Habr!
In dit artikel beginnen we met het verhaal over hoe het van binnen werkt en welke technologieën worden gebruikt bij de ontwikkeling ervan.
Waarom vinden wij dit interessant? Ten eerste omdat het 1C:Enterprise 8-platform een grote applicatie (meer dan 10 miljoen regels code) is in C++ (client, server, enz.), JavaScript (webclient) en, meer recentelijk, En . Grote projecten kunnen in ieder geval interessant zijn vanwege hun schaal, omdat problemen die onzichtbaar zijn in een kleine codebasis in dergelijke projecten volop naar voren komen. Ten tweede is “1C:Enterprise” een repliceerbaar product in een doos, en er zijn maar heel weinig artikelen over dergelijke ontwikkelingen op Habré. Het is ook altijd interessant om te weten hoe het leven in andere teams en bedrijven is.
Dus laten we beginnen. In dit artikel geven we een overzicht van enkele van de technologieën die in het platform worden gebruikt en schetsen we het landschap, zonder diep in de implementatie te duiken. Voor veel mechanismen zou een gedetailleerd verhaal een apart artikel vergen, en voor sommige een heel boek!
Om te beginnen is het de moeite waard om over de basiszaken te beslissen: wat het 1C:Enterprise-platform is en uit welke componenten het bestaat. Het antwoord op deze vraag is niet zo eenvoudig, omdat de term ‘Platform’ (om het kort te houden zullen we het zo noemen) verwijst naar een middel voor het ontwikkelen van bedrijfsapplicaties, een runtime-omgeving en beheertools. Grofweg zijn de volgende onderdelen te onderscheiden:
- servercluster
- “thin” client die verbinding kan maken met de server via http en zijn eigen binaire protocol
- client voor het werken in een tweelaagse architectuur met een database op een harde schijf of netwerkmap
- web cliënt
- beheertools voor applicatieservers
- ontwikkelomgeving (bekend als Configurator)
- runtime-omgeving voor iOS, Android en Windows Phone (mobiel platform 1C)
Al deze onderdelen, met uitzondering van de webclient, zijn geschreven in C++. Daarnaast is er de onlangs aangekondigde , geschreven in Java.
Native apps
C++03 wordt gebruikt om native applicaties te ontwikkelen. Voor Windows wordt Microsoft Visual C++ 12 (een profiel dat compatibel is met Windows XP) gebruikt als compiler, en voor Linux en Android - gcc 4.8, voor iOS - clang 5.0. De gebruikte standaardbibliotheek is voor alle besturingssystemen en compilers hetzelfde: STLPort. Deze oplossing verkleint de kans op STL-implementatiespecifieke fouten. We zijn momenteel van plan om te migreren naar de STL-implementatie die bij CLang wordt geleverd, omdat STLPort is stopgezet en niet compatibel is met de C++11-modus van gcc.
De codebasis van de server is voor 99% gebruikelijk, die van de client voor 95%. Bovendien gebruikt zelfs het mobiele platform dezelfde C++-code als de ‘grote’, hoewel het percentage unificatie daar iets lager is.
Zoals de meeste C++-gebruikers beweren we niet dat we 100% van de mogelijkheden van de taal en zijn bibliotheken gebruiken. We gebruiken Boost dus praktisch niet, en een van de taalfuncties is dynamische typecasting. Tegelijkertijd maken we actief gebruik van:
- STL (specifiek strings, containers en algoritmen)
- meervoudige erfenis, incl. overerving van meerdere implementaties
- Sjablonen
- uitzonderingen
- slimme wijzers (implementatie op maat)
Door gebruik te maken van meervoudige overerving van interfaces (volledig abstracte klassen) wordt een componentenmodel mogelijk, dat hieronder zal worden besproken.
Onderdelen
Om de modulariteit te garanderen, is alle functionaliteit onderverdeeld in componenten, dit zijn dynamische bibliotheken (*.dll voor Windows, *.so voor Linux). Er zijn in totaal meer dan honderdvijftig componenten; hier zijn beschrijvingen van enkele ervan:
backend
Bevat de platform-metadata-engine
rekening
Objecten die applicatieontwikkelaars gebruiken om boekhoudgegevens op te bouwen (rekeningschema's en boekhoudregisters)
bsl
Ingebouwde taaluitvoeringsengine
atoombom
Aangepaste implementatie van geheugenallocator
dbeng8
Bestandsdatabase-engine. Een eenvoudige bestandsserver-database-engine op basis van ISAM, die ook een eenvoudige SQL-processor bevat
wbasis
Bevat de basisklassen en functies voor het implementeren van de Windows-gebruikersinterface - vensterklassen, GDI-toegang, enz.
Het opsplitsen in meerdere componenten is vanuit verschillende gezichtspunten nuttig:
- Scheiding bevordert een beter ontwerp, in het bijzonder een betere code-isolatie
- Uit een set componenten kunt u flexibel verschillende leveringsmogelijkheden samenstellen:
- Een thin client-installatie zal bijvoorbeeld wbase bevatten, maar geen backend
- maar op de wbase-server zal dit integendeel niet het geval zijn
- beide opties bevatten uiteraard nuke en bsl
Alle componenten die nodig zijn voor deze startoptie worden geladen wanneer het programma start. Dit is met name nodig voor het registreren van SCOM-klassen, die hieronder worden besproken.
SCOM
Voor ontbinding op een lager niveau wordt gebruik gemaakt van het SCOM-systeem, een bibliotheek die qua ideologie vergelijkbaar is met ATL. Voor degenen die nog niet met ATL hebben gewerkt, zetten we kort de belangrijkste mogelijkheden en features op een rij.
Voor een speciaal ontworpen SCOM-klasse:
- Biedt fabrieksmethoden waarmee u een klasse kunt maken van een ander onderdeel, waarbij u alleen de naam kent (zonder de implementatie bekend te maken)
- Biedt een slimme pointer-infrastructuur voor het tellen van referenties. De levensduur van de SCOM-klasse hoeft niet handmatig te worden gecontroleerd
- Hiermee kunt u uitzoeken of een object een specifieke interface implementeert en automatisch een pointer naar het object omzetten in een pointer naar de interface
- Maak een serviceobject dat altijd toegankelijk is via de get_service-methode, enz.
U kunt bijvoorbeeld een klasse beschrijven voor het lezen van JSON (bijvoorbeeld JSONStreamReader) in de component json.dll.
Klassen en instanties kunnen worden gemaakt op basis van andere componenten; ze moeten worden geregistreerd in de SCOM-machine:
SCOM_CLASS_ENTRY(JSONStreamReader)
Deze macro beschrijft een speciale statische recorderklasse, waarvan de constructor wordt aangeroepen wanneer de component in het geheugen wordt geladen.
Hierna kunt u er een exemplaar van maken in een andere component:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Ter ondersteuning van de dienstverlening biedt SCOM een aanvullende, vrij complexe infrastructuur. Centraal daarin staat het concept van een SCOM-proces, dat dient als container voor het uitvoeren van services (dat wil zeggen, de rol speelt van Service Locator), en ook een binding met gelokaliseerde bronnen bevat. Het SCOM-proces is gekoppeld aan de OS-thread. Dankzij dit kunt u binnen de applicatie dergelijke diensten ontvangen:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Bovendien kunt u, door logische (SCOM) processen te schakelen die aan een thread zijn gekoppeld, applicaties krijgen die praktisch onafhankelijk zijn vanuit het oogpunt van de informatieruimte, en die binnen dezelfde thread draaien. Dit is hoe onze thin client werkt met een bestandsdatabase: binnen één OS-proces zijn er twee SCOM-processen, één geassocieerd met de client en de tweede met de server. Deze aanpak stelt ons in staat het schrijven van code te verenigen die zowel op de lokale bestandsdatabase als in de “echte” client-serverversie werkt. De prijs voor een dergelijke uniformiteit is overhead, maar de praktijk leert dat het de moeite waard is.
Op basis van het SCOM-componentenmodel worden zowel de bedrijfslogica als het interfacegedeelte van 1C: Enterprise geïmplementeerd.
Gebruikersomgeving
Trouwens, over interfaces. We gebruiken geen standaard Windows-besturingselementen; onze controles worden rechtstreeks op de Windows API geïmplementeerd. Voor de Linux-versie is er een laag gemaakt die werkt via de wxWidgets-bibliotheek.
De bibliotheek met besturingselementen is niet afhankelijk van andere delen van 1C:Enterprise en wordt door ons gebruikt in verschillende andere kleine interne hulpprogramma's.
In de loop van de jaren van ontwikkeling van 1C:Enterprise is het uiterlijk van de bedieningselementen veranderd, maar een serieuze verandering in de principes vond slechts één keer plaats, in 2009, met de release van versie 8.2 en de komst van “beheerde formulieren”. Naast het veranderen van het uiterlijk is het principe van de formulierindeling fundamenteel veranderd: er was een afwijzing van pixel-voor-pixel positionering van elementen ten gunste van een vloeiende lay-out van elementen. Bovendien werken de besturingselementen in het nieuwe model niet rechtstreeks met domeinobjecten, maar met speciale DTO’s ().
Deze wijzigingen maakten het mogelijk om een 1C:Enterprise-webclient te maken die de C++-logica van JavaScript-besturingselementen repliceert. We proberen de functionele gelijkwaardigheid tussen thin- en webclients te behouden. In gevallen waarin dit niet mogelijk is, bijvoorbeeld vanwege beperkingen van de beschikbare JavaScript-API (de mogelijkheid om met bestanden te werken is bijvoorbeeld zeer beperkt), implementeren we vaak de benodigde functionaliteit met behulp van browserextensies geschreven in C++. Momenteel ondersteunen we Internet Explorer en Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows en Linux) en Safari (MacOS).
Daarnaast wordt er gebruik gemaakt van managed formulierentechnologie om een interface te creëren voor mobiele applicaties op het 1C-platform. Op mobiele apparaten wordt de weergave van besturingselementen geïmplementeerd met behulp van technologieën die eigen zijn aan het besturingssysteem, maar voor de formulierlay-outlogica en interfacereactie wordt dezelfde code gebruikt als in het ‘grote’ 1C:Enterprise-platform.
1C-interface op Linux OS
1C-interface op een mobiel apparaat
1C-interface op andere platforms
1C-interface op Windows OS
Interface 1C - webclient
Open source
Hoewel we geen standaardbibliotheken voor C++-ontwikkelaars onder Windows gebruiken (MFC, besturingselementen uit WinAPI), schrijven we niet alle componenten zelf. De bibliotheek is al genoemd , en we gebruiken ook:
- voor het werken met HTTP en FTP.
- voor het werken met cryptografie en het tot stand brengen van TLS-verbindingen
- voor XML-parsering
- voor het werken met mailprotocollen (POP3, SMTP, IMAP)
- om e-mailberichten te parseren
- voor het opslaan van gebruikerslogboeken
- voor internationalisering
De lijst gaat verder.
Daarnaast gebruiken wij een sterk aangepaste versie и bij het ontwikkelen van unit-tests.
De bibliotheken vereisten aanpassing om compatibel te zijn met het SCOM-componentorganisatiemodel.
De prevalentie van 1C maakt het platform een uitstekende krachttest voor de bibliotheken die erin worden gebruikt. Een verscheidenheid aan gebruikers en scenario's brengt snel fouten aan het licht in zelfs de meest zelden gebruikte codegebieden. Wij corrigeren ze zelf en proberen ze terug te geven aan de bibliotheekauteurs. De ervaring van interactie blijkt heel anders te zijn.
Ontwikkelaars и reageer snel op pull-requests, maar de patch zit er bijvoorbeeld in Het is ons nooit gelukt het terug te geven.
Conclusie
In het artikel hebben we verschillende belangrijke aspecten van de ontwikkeling van het 1C: Enterprise-platform besproken. Binnen de beperkte reikwijdte van het artikel hebben we slechts enkele, naar onze mening, interessante aspecten aangestipt.
Een algemene beschrijving van de verschillende platformmechanismen is te vinden .
Welke onderwerpen zouden voor u interessant zijn in toekomstige artikelen?
Hoe wordt het mobiele platform 1C geïmplementeerd?
Beschrijving van de interne structuur van de webclient?
Of misschien ben je geïnteresseerd in het proces van het selecteren van functies voor nieuwe releases, het ontwikkelen en testen ervan?
Schrijf in de reacties!
Bron: www.habr.com