Helló, Habr!
Ebben a cikkben elkezdjük elmesélni, hogyan is működik belülről és milyen technológiákat használnak a fejlesztése során.
Miért gondoljuk, hogy ez érdekes? Először is, mert a „1C:Enterprise 8” platform egy nagy (több mint 10 millió sor kód) C++ (kliense, szerver, stb.), JavaScript (webkliens) alkalmazás, és mostanában még . A nagy projektek érdekessége legalábbis a méretük miatt is megmutatkozik, hiszen a kis kódalapokban észrevétlen kérdések nagyprojektekben teljesen új fényt kapnak. Másodszor, a „1C:Enterprise” egy tömegesen forgalmazott, „dobozos” termék, és szinte nincs cikk az ilyen fejlesztésekről a Habrón. Ráadásul mindig érdekes megtudni, hogyan élnek más csapatokban és cégeknél.
Lássuk hát. Ebben a cikkben áttekintést adunk néhány technológiáról, amelyeket a platformban alkalmaznak, felvázoljuk a tájat, anélkül, hogy mélyrehatóan belemennénk a megvalósításba. Végül is, sok mechanizmus részletes bemutatása önálló cikket igényelne, míg néhány másik esetleg egy teljes könyvet!
Elsőként érdemes tisztázni az alapvető dolgokat – mi az a „1C:Enterprise” platform, és milyen összetevőkből áll. Erre a kérdésre nem olyan egyszerű válaszolni, mert a „Platforma” (röviden erre fogunk utalni) alatt értjük a üzleti alkalmazások fejlesztési eszközét, a végrehajtási környezetét és az adminisztrációs eszközöket. Feltételesen az alábbi összetevőkre különíthetjük el:
- szerverklaszter
- „vékony” kliens, amely képes HTTP-n és saját bináris protokollján csatlakozni a szerverhez
- kliens, amely kétlépcsős architektúrával működik, egy merevlemezen vagy hálózati mappában elhelyezett DB-vel
- webkliens
- alkalmazásszerver adminisztrációs eszközei
- fejlesztési környezet (ismertebb nevén Konfigurátor)
- végrehajtási környezet iOS, Android és Windows Phone számára (1C mobilplatform)
Mindezek a részek, a webkliens kivételével, C++ nyelven íródtak. Ezen kívül létezik egy nemrégiben bejelentett , amely Java nyelven készült.
Natív alkalmazások
A natív alkalmazások fejlesztéséhez a C++03-at használjuk. Windows alatt a Microsoft Visual C++ 12 (Windows XP-vel kompatibilis profil) szolgál fordítóként, míg Linux és Android alatt a gcc 4.8, iOS alatt pedig a clang 5.0. A standard könyvtár minden operációs rendszerhez és fordítóhoz egységes — STLPort. Ez a megoldás csökkenti az STL megvalósításával kapcsolatos hibák valószínűségét. Jelenleg tervezzük az STL CLang által biztosított megvalósítására való áttérést, mivel az STLPort fejlődése leállt, és nem kompatibilis a C++11 támogatás bekapcsolt módjával a gcc-ben.
A szerver kódalapja 99%-ban közös, míg az ügyfél 95%-os közös kódbázissal rendelkezik. Sőt, még a mobil platform is ugyanazt a C++ kódot használja, mint a "nagy", bár ott az egységesítés mértéke valamivel alacsonyabb.
A legtöbb C++ felhasználóhoz hasonlóan mi sem törekszünk a nyelv és könyvtárai 100%-os kihasználására. Szinte soha nem használjuk a Boost-ot, és a nyelv lehetőségei közül is csak a dinamikus típusátalakításra támaszkodunk. Ezzel szemben aktívan alkalmazzuk:
- STL (különösen a karakterláncok, konténerek és algoritmusok)
- többszörös öröklés, beleértve a többszörös implementációs öröklést
- sablonok
- kivételkezelés
- okos mutatók (saját megvalósítás)
A többszörös interfész-öröklés (teljesen absztrakt osztályok) révén lehetővé válik egy komponensalapú modell, amelyről később lesz szó.
Összetevők
A modularitás biztosítása érdekében az összes funkciót dinamikus könyvtárakként (*.dll Windows alatt, *.so Linux alatt) megosztva valósítjuk meg. Összesen több mint másfél száz komponensünk van, ezek közül néhányat a következőkben ismertetünk:
backend
Tartalmazza a platform metadaton motorját
accnt
Azok az objektumok, amelyeket az alkalmazásfejlesztők a könyvelés felépítéséhez használnak (számlaterv és könyvelési nyilvántartások)
bsl
A beágyazott nyelv végrehajtási motorja
nuke
Saját memóriaallokátor megvalósítása
dbeng8
Fájl alapú adatbázis motor. Egy egyszerű fájl-szerver adatbázis gép, amely az ISAM-on alapul, és tartalmaz egy egyszerű SQL feldolgozót is
wbase
Tartalmazza a Windows felhasználói felületének megvalósításához szükséges alap osztályokat és funkciókat — ablakos osztályok, hozzáférés a GDI-hez, stb.
A számos komponensre való szétválasztás több szempontból is hasznos:
- A szétválasztás jobb tervezést segít, különösen a kód jobb izolálását.
- A komponenscsomagból rugalmasan különböző szállítási verziókat lehet összeállítani:
- Például a vékony ügyfél telepítése tartalmazni fogja a wbase-t, de nem lesz backend.
- A wbase szerveren viszont nem lesz.
- Mindkét variáns természetesen tartalmazni fogja a nuke-ot és a bsl-t.
A program indításakor minden szükséges komponenst betöltünk az adott indítási verzióhoz. Ez különösen szükséges a SCOM-osztályok regisztrálásához, amiről alább lesz szó.
SCOM
A SCOM egy alacsonyabb szintű dekompozíciót használ – ideológiailag hasonló az ATL könyvtárhoz. Azok számára, akik még nem dolgoztak ATL-lel, röviden összefoglalom a fő lehetőségeket és jellegzetességeket.
Különösen kialakított SCOM-osztályra:
- Gyári módszereket biztosít, amelyek lehetővé teszik, hogy egy osztályt hozzunk létre egy másik komponensből, csak a neve ismeretében (megvalósítás feltárása nélkül).
- Okos mutatók infrastruktúráját biztosítja referencia számítással. A SCOM-osztály életciklusát nem kell manuálisan nyomon követni.
- Lehetővé teszi annak megállapítását, hogy az objektum megvalósít-e egy adott interfészt, és automatikusan át tudja alakítani az objektum mutatót az interfész mutatójává.
- Szolgáltatás objektumot hozhat létre, mindig elérhető a get_service metóduson keresztül, stb.
Például a json.dll komponensben le lehet írni egy osztályt a JSON olvasására (például JSONStreamReader).
Az osztályokat, példányokat más komponensekből a SCOM-gépen kell regisztrálni:
SCOM_CLASS_ENTRY(JSONStreamReader)
Ez a makró egy speciális statikus osztályregisztrálót ír le, amelynek konstruktora a komponens memóriába töltésekor lesz meghívva.
Ezt követően, egy másik komponensben létrehozhatjuk az példányát:
IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));
A szolgáltatások támogatásához a SCOM egy kiegészítő, meglehetősen bonyolult infrastruktúrát kínál. Ennek középpontjában a SCOM-folyamat fogalma áll, amely a futó szolgáltatások tárolójaként szolgál (azaz betölti a Szolgáltatáskereső szerepét), és tartalmazza a lokalizálható erőforrásokhoz való kötődést. A SCOM-folyamat a rendszerszálhoz kapcsolódik. Ennek köszönhetően az alkalmazáson belül így lehet szolgáltatásokat kapni:
SCOM_Process* process = core::current_process();
if (process)
return get_service(process);
Továbbá, a logikai (SCOM) folyamatok átkapcsolásával, amelyek a folyamathoz kapcsolódnak, gyakorlatilag független alkalmazásteret érhetünk el, amelyek egyetlen folyamat keretein belül futnak. Így működik a vékony kliensünk, amely fájlbázissal dolgozik - egy operációs rendszer belső folyamatában két SCOM-folyamat található, az egyik a klienssel, a másik a szerverrel kapcsolódik. Ez a megközelítés lehetővé teszi a kód egységes írását, amely mind a helyi fájlbázison, mind a "valódi" kliens-szerver változaton fog működni. Az egységesítés ára a felmerülő költségek, de a gyakorlat azt mutatja, hogy megérik az árát.
Az SCOM komponens modelljére alapozva megvalósult az üzleti logika és a felhasználói interfész 1C: Vállalat részére.
Felhasználói felület
Egyébként a felületekről. Nem használunk szabványos Windows-vezérlőket, vezérlőelemeink közvetlenül a Windows API-n keresztül vannak megvalósítva. A Linux verziójához egy köztes réteg készült, amely a wxWidgets könyvtáron keresztül működik.
A vezérlőelemek könyvtára független a "1C: Vállalat" többi részétől, és több kicsi belső segédprogramban is használjuk.
Az 1C: Vállalat fejlődése során a vezérlők megjelenése változott, de a komolyabb elvek változása csak egyszer történt, 2009-ben, a 8.2-es verzió megjelenésével és a "kezelhető űrlapok" bevezetésével. A megjelenés mellett alapvetően megváltozott a forma elrendezésének elve - a pixelek szerinti pozicionálás helyett a flow-koncepcióra való áttérés történt. Ráadásul az új modellben a vezérlőelemek nem közvetlenül a domain objektumokkal dolgoznak, hanem speciális DTO-kkal ().
Ezek a változások lehetővé tették a webkliens "1C: Vállalat" létrehozását, amely JavaScripten megismétli a C++ vezérlők logikáját. Arra törekszünk, hogy funkcionális egyenértékűséget tartsunk fenn a vékony és a webkliens között. Amikor ez lehetetlen, például az elérhető JavaScript API-k korlátai miatt (például a fájlokkal való munka lehetősége nagyon korlátozott), gyakran valósítunk meg szükséges funkciókat böngészőbővítmények segítségével, amelyeket C++ nyelven írtunk. Jelenleg az Internet Explorer és Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows és Linux) és Safari (MacOS) böngészőket támogatjuk.
A 1C mobil alkalmazásainak felületét az irányított formák technológiája használja. Mobil eszközökön a vezérlők megjelenítése az operációs rendszer natív technológiáival valósul meg, de a formák elrendezésének logikája és a felület reakciói ugyanazt a kódot használják, mint a „nagy” 1C:Vállalat platformon.
1C felület Linux operációs rendszeren
1C felület mobil eszközön
1C felület más platformokon 
1C felület Windows operációs rendszeren
1C — webes kliens
Nyílt forráskód
Bár nem használunk olyan, a C++ fejlesztők számára megszokott könyvtárakat Windows alatt (MFC, WinAPI vezérlők), nem minden komponenst magunk írunk. Már említést nyert a , és emellett használjuk:
- HTTP és FTP kezelésére.
- titkosítási munka és TLS kapcsolatok létrehozására
- XML parsolására
- levélprotokollokkal (POP3, SMTP, IMAP) való munkára
- elektronikus levelek üzeneteinek parsolására
- a felhasználói tevékenységek naplózásához
- nemzetközivé tételhez
A lista még folytatható.
Emellett erősen módosított változatát használjuk a és egységtesztek fejlesztéséhez.
A könyvtárakat alkalmazkodásra kényszerítette a komponens szervezeti SCOM-modelljével való kompatibilitás érdekében.
A 1C elterjedtsége kiváló ellenőrzési lehetőséget biztosít az abban használt könyvtáraknak. A felhasználók és a forgatókönyvek sokfélesége gyorsan felfedi a hibákat még a legkevésbé használt kódrészekben is. A hibákat javítjuk a saját rendszerünkben és igyekszünk visszaadni a könyvtárak készítőinek. A tapasztalataink változatosak.
Fejlesztők és gyorsan reagálnak a pull-requestekre, de a patch, például a soha nem sikerült visszaadnunk.
Zárás
A cikkben a „1C: Vállalat” platform fejlesztésének néhány alapvető aspektusát érintettük. A cikk korlátozott terjedelmében csak néhány érdekesnek tartott aspektust említettünk meg.
A platform különféle mechanizmusainak általános leírását itt tekinthetjük meg: .
Milyen témák érdekelnének Önöket a következő cikkekben?
Hogyan valósult meg a 1C mobil platform?
A webes kliens belső felépítése?
Vagy talán érdekelné Önöket az új kiadások funkcióinak kiválasztásának, fejlesztésének és tesztelésének folyamata?
Írjanak megjegyzéseikben!
Forrás: habr.com
