Szia Habr!
Ebben a cikkben elkezdjük a történetet arról, hogyan működik belül és milyen technológiákat alkalmaznak fejlesztése során.
Miért gondoljuk, hogy ez érdekes? Először is azért, mert az 1C:Enterprise 8 platform egy nagy (több mint 10 millió kódsoros) alkalmazás C++-ban (kliens, szerver stb.), JavaScriptben (webkliens), és újabban . A nagy projektek legalább a méretük miatt lehetnek érdekesek, mert az ilyen projektekben a kis kódbázisban láthatatlan problémák teljes mértékben felmerülnek. Másodszor, az „1C:Enterprise” egy replikálható, „dobozos” termék, és nagyon kevés cikk található a Habrén ilyen fejlesztésekről. Mindig érdekes tudni, hogy más csapatokban és társaságokban milyen az élet.
Tehát kezdjük. Ebben a cikkben áttekintést adunk néhány, a platformon használt technológiáról, és felvázoljuk a tájat anélkül, hogy mélyen belemerülnénk a megvalósításba. Valóban, sok mechanizmus esetében egy részletes történethez külön cikkre, egyeseknél pedig egy egész könyvre lenne szükség!
Először is érdemes eldönteni az alapvető dolgokat - mi az 1C:Enterprise platform és milyen összetevőkből áll. A kérdésre a válasz nem ilyen egyszerű, mert a „Platform” kifejezés (a rövidség kedvéért így fogjuk nevezni) az üzleti alkalmazások, a futtatókörnyezet és az adminisztrációs eszközök fejlesztésének eszközére utal. Nagyjából a következő összetevőket lehet megkülönböztetni:
- szerverfürt
- „vékony” kliens, amely http-n és saját bináris protokollján keresztül képes csatlakozni a szerverhez
- kliens kétszintű architektúrában való munkához, merevlemezen vagy hálózati mappában található adatbázissal
- webes kliens
- alkalmazásszerver adminisztrációs eszközök
- fejlesztői környezet (Configurator néven ismert)
- futásidejű környezet iOS, Android és Windows Phone rendszerhez (mobil platform 1C)
Mindezek a részek, a webes kliens kivételével, C++ nyelven íródnak. Ezen kívül ott van a nemrég bejelentett , Java nyelven írva.
Natív alkalmazások
A C++03 natív alkalmazások fejlesztésére szolgál. Windows esetén a Microsoft Visual C++ 12 (Windows XP-vel kompatibilis profil) fordítóként, Linux és Android esetén pedig a gcc 4.8, iOS esetén pedig a clang 5.0. A használt szabványos könyvtár minden operációs rendszerhez és fordítóhoz ugyanaz – STLPort. Ez a megoldás csökkenti az STL implementáció-specifikus hibák valószínűségét. Jelenleg azt tervezzük, hogy áttérünk a CLang-gal szállított STL-implementációra, mivel az STLPort már megszűnt, és nem kompatibilis a gcc C++11-kompatibilis módjával.
A szerver kódbázisa 99%-ban közös, a kliensé 95%-ban. Sőt, még a mobilplatform is ugyanazt a C++ kódot használja, mint a „nagy”, bár ott valamivel alacsonyabb az egységesítés aránya.
A legtöbb C++ felhasználóhoz hasonlóan mi sem állítjuk, hogy 100%-ban használjuk a nyelv és könyvtárai képességeit. Tehát gyakorlatilag nem használjuk a Boost-ot, és az egyik nyelvi funkció a dinamikus típusú casting. Ugyanakkor aktívan használjuk:
- STL (konkrétan karakterláncok, tárolók és algoritmusok)
- többszörös öröklődés, beleértve többszörös megvalósítási öröklődés
- Minták
- kivételek
- intelligens mutatók (egyéni megvalósítás)
Az interfészek többszörös öröklődésének (teljesen absztrakt osztályok) használatával lehetővé válik egy komponens modell, amelyről az alábbiakban lesz szó.
Alkatrészek
A modularitás biztosítása érdekében minden funkcionalitás összetevőkre van osztva, amelyek dinamikus könyvtárak (*.dll Windows-hoz, *.so Linuxhoz). Összesen több mint százötven összetevőből áll, ezek közül néhány leírása itt található:
backend
A platform metaadat-motorját tartalmazza
accnt
Objektumok, amelyeket az alkalmazásfejlesztők használnak számviteli rekordok (számlatáblázatok és számviteli nyilvántartások) létrehozásához
bsl
Beágyazott nyelvi végrehajtó motor
nuke
Memórialeosztó egyedi megvalósítása
dbeng8
Fájl adatbázis motor. Egy egyszerű, ISAM alapú fájlkiszolgáló adatbázis-motor, amely egy egyszerű SQL processzort is tartalmaz
wbase
Tartalmazza a Windows felhasználói felület megvalósításához szükséges alaposztályokat és függvényeket - ablakosztályokat, GDI hozzáférést stb.
A több komponensre bontás több szempontból is hasznos:
- Az elválasztás elősegíti a jobb tervezést, különösen a jobb kódelválasztást
- Az alkatrészkészletből rugalmasan összeállíthatja a különböző szállítási lehetőségeket:
- Például egy vékony kliens telepítés tartalmazni fogja a wbase-t, de nem lesz háttérprogramja
- de a wbase szerveren éppen ellenkezőleg, nem lesz
- mindkét opció természetesen tartalmazni fogja a nuke-ot és a bsl-t
Az indítási opcióhoz szükséges összes összetevő betöltődik a program indításakor. Ez különösen az SCOM osztályok regisztrálásához szükséges, amelyet az alábbiakban tárgyalunk.
SCOM
Az alacsonyabb szintű dekompozícióhoz az SCOM rendszert használják, az ATL-hez hasonló ideológiájú könyvtárat. Azok számára, akik még nem dolgoztak az ATL-lel, röviden felsoroljuk a főbb képességeket és funkciókat.
Egy speciálisan kialakított SCOM osztályhoz:
- Olyan gyári metódusokat biztosít, amelyek lehetővé teszik osztály létrehozását egy másik összetevőből, csak a nevének ismeretében (a megvalósítás felfedése nélkül)
- Referenciaszámláló intelligens mutató infrastruktúrát biztosít. Az SCOM osztály élettartamát nem kell manuálisan felügyelni
- Lehetővé teszi annak megállapítását, hogy egy objektum megvalósít-e egy adott interfészt, és automatikusan átalakítja az objektum mutatóját az interfész mutatójává
- Hozzon létre egy szolgáltatásobjektumot, amely mindig elérhető a get_service metóduson stb.
Például leírhat egy osztályt a JSON olvasásához (például JSONStreamReader) a json.dll összetevőben.
Osztályok és példányok más összetevőkből is létrehozhatók, ezeket regisztrálni kell az SCOM gépen:
SCOM_CLASS_ENTRY(JSONStreamReader)
Ez a makró egy speciális statikus rögzítő osztályt ír le, amelynek a konstruktora a komponens memóriába való betöltésekor kerül meghívásra.
Ezt követően létrehozhat belőle egy példányt egy másik komponensben:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
A szolgáltatások támogatására az SCOM egy további, meglehetősen összetett infrastruktúrát kínál. Ennek központi eleme az SCOM-folyamat koncepciója, amely konténerként szolgál a szolgáltatások futtatásához (azaz a Service Locator szerepét tölti be), és tartalmaz egy kötést a lokalizált erőforrásokhoz. Az SCOM folyamat az operációs rendszer szálához van kötve. Ennek köszönhetően az alkalmazáson belül a következő szolgáltatásokat veheti igénybe:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Sőt, egy szálhoz kötött logikai (SCOM) folyamatok váltásával az információs tér szempontjából gyakorlatilag független, egy szálon belül futó alkalmazásokat kaphatunk. Vékony kliensünk így működik egy fájladatbázissal - egy operációs rendszer folyamaton belül két SCOM-folyamat található, az egyik a klienshez, a másik pedig a szerverhez kapcsolódik. Ez a megközelítés lehetővé teszi számunkra, hogy egységesítsük a kódírást, amely mind a helyi fájl adatbázison, mind az „igazi” kliens-szerver verzióban működik. Az ilyen egységesség ára rezsi, de a gyakorlat azt mutatja, hogy megéri.
Az SCOM komponensmodell alapján az 1C: Enterprise üzleti logikája és interfész része egyaránt megvalósul.
Felhasználói felület
Egyébként a felületekről. Nem használunk szabványos Windows-vezérlőket, vezérlőink közvetlenül a Windows API-n vannak implementálva. A Linux verzióhoz készült egy réteg, amely a wxWidgets könyvtáron keresztül működik.
A vezérlők könyvtára nem függ az 1C:Enterprise más részeitől, és számos más kis belső segédprogramban is használjuk.
Az 1C:Enterprise fejlesztésének évei során a vezérlőelemek megjelenése megváltozott, de komoly elvváltozás csak egyszer, 2009-ben, a 8.2-es verzió megjelenésével és a „menedzselt űrlapok” megjelenésével történt. A megjelenés megváltoztatása mellett alapvetően megváltozott a formaelrendezés elve is - az elemek pixelenkénti pozicionálását elutasították az elemek flow-elrendezése javára. Ráadásul az új modellben a vezérlők nem közvetlenül tartományobjektumokkal, hanem speciális DTO-kkal ().
Ezek a változtatások lehetővé tették egy 1C:Enterprise webkliens létrehozását, amely replikálja a JavaScript vezérlők C++ logikáját. Igyekszünk fenntartani a funkcionális egyenértékűséget a vékony és webes kliensek között. Azokban az esetekben, amikor ez nem lehetséges, például az elérhető JavaScript API korlátai miatt (például a fájlokkal való munkavégzés lehetősége nagyon korlátozott), gyakran C++ nyelven írt böngészőbővítmények segítségével valósítjuk meg a szükséges funkcionalitást. Jelenleg az Internet Explorert és a Microsoft Edge-t (Windows), a Google Chrome-ot (Windows), a Firefoxot (Windows és Linux) és a Safarit (MacOS) támogatjuk.
Ezenkívül a kezelt űrlapok technológiáját használják interfész létrehozására a mobil alkalmazásokhoz az 1C platformon. A mobileszközökön a vezérlőelemek megjelenítése az operációs rendszerben natív technológiákkal valósul meg, de az űrlapelrendezési logika és az interfész válasza ugyanazt a kódot használja, mint a „nagy” 1C:Enterprise platformon.
1C interfész Linux operációs rendszeren
1C interfész egy mobil eszközön
1C interfész más platformokon
1C interfész Windows operációs rendszeren
1C interfész - webes kliens
Nyílt forráskód
Bár nem használunk szabványos könyvtárakat a C++ fejlesztők számára Windows alatt (MFC, vezérlők WinAPI-ból), nem írunk minden összetevőt magunk. A könyvtárról már volt szó , és mi is használjuk:
- HTTP-vel és FTP-vel való munkához.
- kriptográfiával való munkához és TLS-kapcsolatok létrehozásához
- XML elemzéshez
- levelezési protokollokkal való munkához (POP3, SMTP, IMAP)
- az e-mail üzenetek elemzéséhez
- felhasználói naplók tárolására
- a nemzetközivé válás érdekében
A lista folytatódik.
Ezenkívül egy erősen módosított változatot használunk и egységtesztek kidolgozásakor.
A könyvtárakat adaptálni kellett ahhoz, hogy kompatibilisek legyenek az SCOM komponens-szervezési modellel.
Az 1C elterjedtsége a platformot kiváló erőpróbává teszi a benne használt könyvtárak számára. A különféle felhasználók és forgatókönyvek gyorsan feltárják a hibákat a kód legritkábban használt területein is. Ezeket mi magunk javítjuk és igyekszünk visszaadni a könyvtár szerzőinek. Az interakció tapasztalatai nagyon eltérőek.
Fejlesztők и gyorsan reagál a pull-kérésekre, de a javítás például be Soha nem sikerült visszaadnunk.
Következtetés
A cikkben az 1C: Enterprise platform fejlesztésének több fő szempontját érintettük. A cikk korlátozott terjedelmében csak néhány, véleményünk szerint érdekes szempontot érintettünk.
A különböző platformmechanizmusok általános leírása megtalálható .
Milyen témák érdekelnének a jövőbeni cikkekben?
Hogyan valósul meg az 1C mobilplatform?
A webkliens belső felépítésének leírása?
Vagy talán érdekli az új kiadásokhoz szükséges funkciók kiválasztásának, fejlesztésének és tesztelésének folyamata?
Írd meg kommentben!
Forrás: will.com