Ahoj, Habr!
V tomto článku začneme vyprávět o tom, jak je to uvnitř a jaké technologie jsou při jejím vývoji použity.
Proč si myslíme, že je to zajímavé? Za prvé, protože platforma „1C:Enterprise 8“ je velká (více než 10 milionů řádků kódu) aplikace napsaná v C++ (klient, server atd.), JavaScriptu (webový klient) a, od nedávna, i . Velké projekty bývají zajímavé už jen kvůli rozsahu, protože otázky, které v malé kódové základně zůstávají bez povšimnutí, se v takových projektech dostávají do popředí. Za druhé, „1C:Enterprise“ je replikovatelný, „krabicový“ produkt, a článků o takových vývojích na Habru není mnoho. A navíc je vždy zajímavé dozvědět se, jak žijí v jiných týmech a firmách.
Takže, pojďme na to. V tomto článku poskytneme přehled některých technologií používaných na platformě, načrtneme krajinu, aniž bychom se hluboce ponořili do implementace. Vždyť pro mnohé mechanismy by podrobné vyprávění zasluhovalo samostatný článek, u některých dokonce celou knihu!
Než začneme, je dobré si ujasnit základní věci — co je platforma „1C:Enterprise“ a z jakých komponent se skládá. Odpověď na tuto otázku není tak jednoduchá, protože pod termínem „Platforma“ (pro stručnost ji budeme nazývat právě tak) se rozumí jak nástroj pro vývoj obchodních aplikací, tak prostředí pro provádění a administraci. Zjednodušeně lze vyčlenit následující součásti:
- klastr serverů
- „tenký“ klient schopný se připojit k serveru přes http a vlastním binárním protokolem
- klient pro práci v dvoustupňové architektuře s DB umístěnou na pevném disku nebo síťové složce
- webový klient
- nástroje pro administraci aplikačního serveru
- vývojové prostředí (známé jako Konfigurátor)
- prováděcí prostředí pro iOS, Android a Windows Phone (mobilní platforma 1C)
Všechny tyto části, s výjimkou webového klienta, jsou napsány v C++. Kromě toho byl nedávno oznámen , napsaný v Javě.
Nativní aplikace
Pro vývoj nativních aplikací se používá C++03. Pod Windows je kompilátor Microsoft Visual C++ 12 (profil kompatibilní s Windows XP), zatímco pro Linux a Android se používá gcc 4.8, pro iOS pak clang 5.0. Standardní knihovna je jednotná pro všechny OS a kompilátory — STLPort. Toto řešení snižuje pravděpodobnost chyb specifických pro implementaci STL. V současnosti plánujeme přechod na implementaci STL dodávanou s CLang, protože STLPort přestal být vyvíjen a není kompatibilní s režimem podpory C++11 v gcc.
Kódová základna serveru je společná z 99 %, klienta z 95 %. Navíc i mobilní platforma používá stejný C++ kód jako „velká“, i když s nižším procentem unifikace.
Stejně jako většina uživatelů C++ nemáme ambici využívat 100 % možností jazyka a jeho knihoven. Tak prakticky vůbec nepoužíváme Boost a z možností jazyka — dynamické přetypování. Na druhou stranu aktivně využíváme:
- STL (zejména řetězce, kontejnery a algoritmy)
- vícenásobné dědičnosti, včetně vícenásobné dědičnosti implementace
- šablony
- výjimky
- chytré ukazatele (vlastní implementace)
Díky využití vícenásobné dědičnosti rozhraní (zcela abstraktní třídy) je možná komponentní model, o kterém bude řeč níže.
Komponenty
Pro zajištění modulárnosti je celá funkcionalita rozdělena na komponenty, které představují dynamické knihovny (*.dll pod Windows, *.so pod Linux). Celkem je komponent více než sto padesát, přičemž uvedeme popisy některých z nich:
backend
Obsahuje „motor“ metadat platformy
accnt
Objekty, které aplikační vývojáři používají k tvorbě účetnictví (plány účtů a registrace účetnictví)
bsl
Motor provádění vestavěného jazyka
nuke
Vlastní implementace alokátoru paměti
dbeng8
Motor souborové databáze. Jednoduchý souborový server databází založený na ISAM, zahrnující také jednoduchý SQL procesor
wbase
Obsahuje základní třídy a funkce pro implementaci uživatelského rozhraní Windows — oknové třídy, přístup k GDI atd.
Rozdělení do mnoha komponent je užitečné z několika pohledů:
- Rozdělení přispívá k lepšímu návrhu, zejména k lepší izolaci kódu.
- Z komponentního setu lze flexibilně sestavovat různé varianty dodávek:
- Například instalace tenkého klienta bude obsahovat wbase, ale nebude mít backend
- na serveru wbase, naopak, nebude
- oba varianty budou samozřejmě obsahovat nuke a bsl
Všechny potřebné komponenty pro tuto variantu spuštění se načítají při startu programu. To je zejména důležité pro registraci tříd SCOM, o kterých bude řeč níže.
SCOM
Pro dekompozici na nižší úrovni se používá systém SCOM — ideologicky podobný knihovně ATL. Pro ty, kteří s ATL nepracovali, stručně vyjmenuji hlavní možnosti a vlastnosti.
Pro speciálně definovanou třídu SCOM:
- Poskytuje tovární metody, které umožňují vytvořit třídu z jiné komponenty, přičemž se zná pouze její název (bez odhalení implementace)
- Poskytuje infrastrukturu chytrých ukazatelů s počítáním referencí. O dobu životnosti třídy SCOM se není třeba starat ručně
- Umožňuje zjistit, zda objekt implementuje konkrétní rozhraní a automaticky převést ukazatel na objekt na ukazatel na rozhraní
- Vytvořit objekt-servis, který je vždy dostupný prostřednictvím metody get_service atd.
Například lze v komponentě json.dll popsat třídu pro čtení JSON (například JSONStreamReader).
Třídy, instance lze vytvářet z jiných komponent a je nutné je zaregistrovat v SCOM-stroji:
SCOM_CLASS_ENTRY(JSONStreamReader)
Tento makro popíše speciální statickou třídu-registrační, jejíž konstruktor bude zavolán při načtení komponenty do paměti.
Poté lze vytvořit její instanci v jiné komponentě:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Pro podporu služeb SCOM nabízí dodatečnou, poměrně složitou infrastrukturu. Centrálním pojmem je zde SCOM-proces, který slouží jako kontejner pro spuštěné služby (tzn. plní roli Service Locator) a také obsahuje vazbu na lokalizované zdroje. SCOM proces se váže na vlákno OS. Díky tomu lze uvnitř aplikace takto získávat služby:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Navíc, přepínáním logických (SCOM) procesů spojených s tokem je možné dosáhnout prakticky nezávislých aplikací z pohledu informačního prostoru, které běží v rámci jednoho vlákna. Tak je navržen náš tenký klient, který pracuje s databází souborů - uvnitř jednoho procesu OS se nacházejí dva SCOM procesy, jeden spojený s klientem a druhý se serverem. Tento přístup umožňuje zjednodušení psaní kódu, který funguje jak na místní databázi souborů, tak v "skutečné" variantě klient-server. Cena za tuto jednotnost jsou režijní náklady, ale praxe ukazuje, že za to stojí.
Na základě komponentního modelu SCOM je realizována jak obchodní logika, tak rozhraní 1C: Podnikání.
Uživatelské rozhraní
Mimochodem, o rozhraních. Nepoužíváme standardní ovládací prvky Windows, naše ovládací prvky jsou implementovány přímo pomocí Windows API. Pro verzi pro Linux byla vytvořena mezivrstva, která pracuje prostřednictvím knihovny wxWidgets.
Knihovna ovládacích prvků není závislá na jiných částech "1C: Podnikání" a používáme ji i v několika dalších drobných interních utilitách.
Během let vývoje 1C: Podnikání se vzhled ovládacích prvků měnil, ale zásadní změna principů nastala pouze jednou, v roce 2009, s vydáním verze 8.2 a zavedením "řízených formulářů". Kromě změny vzhledu se zásadně změnil princip uspořádání formuláře - došlo k opuštění pixelového umístění prvků ve prospěch flow uspořádání prvků. Navíc v novém modelu ovládací prvky nepracují přímo s doménovými objekty, ale se speciálními DTO ().
Tyto změny umožnily vytvoření webového klienta "1C: Podnikání", který replikuje C++ logiku ovládacích prvků v JavaScriptu. Snažíme se udržovat funkční ekvivalentnost mezi tenkým a webovým klientem. V případě, že to není možné, například kvůli omezením dostupným v JavaScript API (například možnosti práce se soubory jsou velmi omezené), často implementujeme potřebnou funkčnost pomocí rozšíření pro prohlížeč napsaných v C++. V současnosti podporujeme Internet Explorer a Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows a Linux) a Safari (MacOS).
Kromě toho se technologie řízených formulářů používá k vytvoření rozhraní mobilních aplikací na platformě 1C. Na mobilních zařízeních je vykreslování ovládacích prvků realizováno s využitím "nativních" technologií operačního systému, ale pro logiku uspořádání formuláře a reakce rozhraní se používá stejný kód, jaký je ve "velké" platformě "1C:Enterprise".
Rozhraní 1C na OS Linux
Rozhraní 1C na mobilním zařízení
Rozhraní 1C na jiných platformách 
Rozhraní 1C na OS Windows
Rozhraní 1C — webový klient
Open source
I když nepoužíváme standardní knihovny pro vývojáře C++ pod Windows (MFC, ovládací prvky z WinAPI), ne všechny komponenty vytváříme sami. Již byla zmíněna knihovna , a navíc používáme:
- pro práci s HTTP a FTP.
- pro práci s kryptografií a vytváření TLS spojení
- pro analýzu XML
- pro práci s poštovními protokoly (POP3, SMTP, IMAP)
- pro analýzu e-mailových zpráv
- pro ukládání záznamů o činnosti uživatelů
- pro internacionalizaci
Seznam lze ještě pokračovat.
Kromě toho používáme silně modifikovanou verzi a při vývoji unit testů.
Knihovny si vyžádaly úpravy pro kompatibilitu se SCOM modelem organizace komponent.
Rozšířenost 1C činí platformu vynikajícím testem odolnosti pro knihovny, které v ní používáme. Rozmanitost uživatelů a scénářů rychle odhaluje chyby i v nejméně používaných částech kódu. Opravy provádíme sami a snažíme se je vracet autorům knihoven. Zkušenosti ze spolupráce jsou velmi rozdílné.
Vývojáři a rychle reagují na pull-request, ale patch, například v se nám zatím nepodařilo vrátit.
Závěr
V článku jsme se dotkli několika hlavních aspektů vývoje platformy "1C: Enterprise". V rámci omezeného objemu článku jsme se zmínili pouze o některých zajímavých, podle našeho názoru, aspektech.
Obecný popis různých mechanismů platformy lze najít .
Jaká témata by vás zajímala v následujících článcích?
Jak je realizována mobilní platforma 1C?
Popis vnitřní struktury webového klienta?
Nebo možná vás zajímá proces výběru funkcí pro nové verze, vývoj a testování?
Připomínky pište do komentářů!
Zdroj: habr.com
