Hola Habr!
En aquest article començarem la història sobre com funciona dins i quines tecnologies s'utilitzen en el seu desenvolupament.
Per què creiem que això és interessant? En primer lloc, perquè la plataforma 1C:Enterprise 8 és una gran aplicació (més de 10 milions de línies de codi) en C++ (client, servidor, etc.), JavaScript (client web) i, més recentment, I . Els projectes grans poden ser interessants almenys per la seva escala, perquè els problemes que són invisibles en una base de codi petita sorgeixen amb tota força en aquests projectes. En segon lloc, "1C:Enterprise" és un producte replicable, "en caixa", i hi ha molt pocs articles sobre aquests desenvolupaments a Habré. També sempre és interessant saber com és la vida en altres equips i empreses.
Així que comencem. En aquest article donarem una visió general d'algunes de les tecnologies que s'utilitzen a la plataforma i perfilarem el paisatge, sense aprofundir en la implementació. De fet, per a molts mecanismes, una història detallada requeriria un article a part, i per a alguns, un llibre sencer!
Per començar, val la pena decidir les coses bàsiques: què és la plataforma 1C:Enterprise i de quins components consta. La resposta a aquesta pregunta no és tan senzilla, perquè el terme "Plataforma" (per a la brevetat, l'anomenarem així) es refereix a un mitjà per desenvolupar aplicacions empresarials, un entorn d'execució i eines d'administració. Es poden distingir aproximadament els components següents:
- clúster de servidors
- client "prim" capaç de connectar-se al servidor mitjançant http i el seu propi protocol binari
- client per treballar en una arquitectura de dos nivells amb una base de dades situada en un disc dur o carpeta de xarxa
- client web
- eines d'administració del servidor d'aplicacions
- entorn de desenvolupament (conegut com a configurador)
- entorn d'execució per a iOS, Android i Windows Phone (plataforma mòbil 1C)
Totes aquestes parts, a excepció del client web, estan escrites en C++. A més, hi ha el recentment anunciat , escrit en Java.
Aplicacions natives
C++03 s'utilitza per desenvolupar aplicacions natives. Per a Windows, Microsoft Visual C++ 12 (un perfil compatible amb Windows XP) s'utilitza com a compilador, i per a Linux i Android - gcc 4.8, per a iOS - clang 5.0. La biblioteca estàndard utilitzada és la mateixa per a tots els sistemes operatius i compiladors: STLPort. Aquesta solució redueix la probabilitat d'errors específics d'implementació STL. Actualment estem planejant migrar a la implementació STL que s'envia amb CLang, ja que STLPort s'ha deixat de fabricar i és incompatible amb el mode habilitat C++11 de gcc.
La base de codi del servidor és 99% comú, la del client - 95%. A més, fins i tot la plataforma mòbil utilitza el mateix codi C++ que el "gran", encara que el percentatge d'unificació allà és una mica menor.
Com la majoria dels usuaris de C++, no pretenem utilitzar el 100% de les capacitats del llenguatge i les seves biblioteques. Per tant, pràcticament no fem servir Boost, i una de les característiques del llenguatge és el càsting de tipus dinàmic. Al mateix temps, fem servir activament:
- STL (específicament cadenes, contenidors i algorismes)
- herència múltiple, incl. herència d'implementació múltiple
- plantilles
- excepcions
- punters intel·ligents (implementació personalitzada)
Mitjançant l'ús d'herència múltiple d'interfícies (classes completament abstractes), es fa possible un model de components, que es comentarà a continuació.
Components
Per garantir la modularitat, tota la funcionalitat es divideix en components, que són biblioteques dinàmiques (*.dll per a Windows, *.so per a Linux). Hi ha més de cent cinquanta components en total; aquí hi ha descripcions d'alguns d'ells:
backend
Conté el motor de metadades de la plataforma
accnt
Objectes que els desenvolupadors d'aplicacions utilitzen per crear registres comptables (plans de comptes i registres comptables)
BSL
Motor d'execució del llenguatge incrustat
nuclear
Implementació personalitzada de l'assignador de memòria
dbeng8
Motor de base de dades de fitxers. Un motor de base de dades de servidor de fitxers senzill basat en ISAM, que també inclou un processador SQL senzill
wbase
Conté les classes i funcions bàsiques per implementar la interfície d'usuari de Windows: classes de finestres, accés GDI, etc.
Dividir en diversos components és útil des de diversos punts de vista:
- La separació promou un millor disseny, en particular un millor aïllament del codi
- Des d'un conjunt de components podeu muntar de manera flexible diferents opcions de lliurament:
- Per exemple, una instal·lació de client prim contindrà wbase, però no tindrà backend
- però al servidor wbase, al contrari, no ho serà
- ambdues opcions, per descomptat, contindran nuke i bsl
Tots els components necessaris per a aquesta opció de llançament es carreguen quan s'inicia el programa. Això, en particular, és necessari per registrar les classes SCOM, que es comentaran a continuació.
Scom
Per a la descomposició a un nivell inferior, s'utilitza el sistema SCOM, una biblioteca similar en ideologia a ATL. Per a aquells que no han treballat amb ATL, enumerem breument les principals capacitats i característiques.
Per a una classe SCOM especialment dissenyada:
- Proporciona mètodes de fàbrica que us permeten crear una classe a partir d'un altre component coneixent només el seu nom (sense revelar la implementació)
- Proporciona una infraestructura de punter intel·ligent que compta amb referències. La vida útil de la classe SCOM no s'ha de controlar manualment
- Permet esbrinar si un objecte implementa una interfície específica i convertir automàticament un punter a l'objecte en un punter a la interfície
- Creeu un objecte de servei que sigui sempre accessible mitjançant el mètode get_service, etc.
Per exemple, podeu descriure una classe per llegir JSON (per exemple, JSONStreamReader) al component json.dll.
Les classes i les instàncies es poden crear a partir d'altres components; s'han de registrar a la màquina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Aquesta macro descriu una classe especial de gravadora estàtica, el constructor de la qual es cridarà quan es carregui el component a la memòria.
Després d'això, podeu crear-ne una instància en un altre component:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Per donar suport als serveis, SCOM ofereix una infraestructura addicional força complexa. El concepte central d'un procés SCOM, que serveix com a contenidor per executar serveis (és a dir, fa el paper de Localitzador de serveis) i també conté una vinculació a recursos localitzats. El procés SCOM està lligat al fil del sistema operatiu. Gràcies a això, dins de l'aplicació podeu rebre serveis com aquest:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
A més, canviant processos lògics (SCOM) lligats a un fil, podeu obtenir aplicacions pràcticament independents des del punt de vista de l'espai d'informació, que s'executen dins del mateix fil. Així és com funciona el nostre client prim amb una base de dades de fitxers: dins d'un procés del sistema operatiu hi ha dos processos SCOM, un associat amb el client i el segon amb el servidor. Aquest enfocament ens permet unificar l'escriptura de codi que funcionarà tant a la base de dades local de fitxers com a la versió "real" client-servidor. El preu d'aquesta uniformitat és general, però la pràctica demostra que val la pena.
Basat en el model de components SCOM, s'implementen tant la lògica empresarial com la part d'interfície d'1C: Enterprise.
Interfície d'usuari
Per cert, sobre les interfícies. No fem servir controls estàndard de Windows; els nostres controls s'implementen directament a l'API de Windows. Per a la versió de Linux, s'ha fet una capa que funciona a través de la biblioteca wxWidgets.
La biblioteca de controls no depèn d'altres parts d'1C:Enterprise i la fem servir en diverses altres petites utilitats internes.
Al llarg dels anys de desenvolupament d'1C:Enterprise, l'aspecte dels controls ha canviat, però un canvi seriós en els principis només es va produir una vegada, el 2009, amb el llançament de la versió 8.2 i l'arribada dels "formularis gestionats". A més de canviar l'aparença, el principi de la disposició del formulari ha canviat fonamentalment: hi ha hagut un rebuig del posicionament píxel per píxel dels elements a favor de la disposició del flux d'elements. A més, en el nou model, els controls no funcionen directament amb objectes de domini, sinó amb DTO especials ().
Aquests canvis van permetre crear un client web 1C:Enterprise que replica la lògica C++ dels controls JavaScript. Intentem mantenir l'equivalència funcional entre clients lleugers i clients web. En els casos en què això no és possible, per exemple a causa de les limitacions de l'API JavaScript disponible (per exemple, la capacitat de treballar amb fitxers és molt limitada), sovint implementem la funcionalitat necessària mitjançant extensions de navegador escrites en C++. Actualment admetem Internet Explorer i Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows i Linux) i Safari (MacOS).
A més, s'utilitza la tecnologia de formularis gestionats per crear una interfície per a aplicacions mòbils a la plataforma 1C. Als dispositius mòbils, la representació dels controls s'implementa mitjançant tecnologies natives del sistema operatiu, però per a la lògica de disseny del formulari i la resposta de la interfície, s'utilitza el mateix codi que a la plataforma "gran" 1C:Enterprise.
Interfície 1C al sistema operatiu Linux
Interfície 1C en un dispositiu mòbil
Interfície 1C en altres plataformes
Interfície 1C al sistema operatiu Windows
Interfície 1C - client web
Codi obert
Tot i que no fem servir biblioteques estàndard per a desenvolupadors de C++ a Windows (MFC, controls de WinAPI), no escrivim tots els components nosaltres mateixos. La biblioteca ja ha estat esmentada , i també fem servir:
- per treballar amb HTTP i FTP.
- per treballar amb criptografia i establir connexions TLS
- per a l'anàlisi XML
- per treballar amb protocols de correu (POP3, SMTP, IMAP)
- per analitzar missatges de correu electrònic
- per emmagatzemar els registres dels usuaris
- per a la internacionalització
La llista continua.
A més, utilitzem una versió molt modificada и quan es desenvolupen proves unitàries.
Les biblioteques van requerir una adaptació per ser compatibles amb el model d'organització dels components SCOM.
La prevalença d'1C fa que la plataforma sigui una excel·lent prova de força per a les biblioteques que s'hi fan servir. Una varietat d'usuaris i escenaris revelen ràpidament errors fins i tot en les àrees de codi més poc utilitzades. Els corregim nosaltres mateixos i intentem retornar-los als autors de la biblioteca. L'experiència de la interacció resulta ser molt diferent.
Desenvolupadors и respon ràpidament a les sol·licituds d'extracció, però el pegat, per exemple, entra No hem aconseguit tornar-lo mai.
Conclusió
En l'article vam tocar diversos aspectes principals del desenvolupament de la plataforma 1C: Enterprise. En l'abast limitat de l'article, només vam tocar alguns aspectes interessants, segons la nostra opinió.
Es pot trobar una descripció general dels diferents mecanismes de la plataforma .
Quins temes serien del vostre interès en els propers articles?
Com s'implementa la plataforma mòbil 1C?
Descripció de l'estructura interna del client web?
O potser us interessa el procés de selecció de funcions per a noves versions, desenvolupament i prova?
Escriu als comentaris!
Font: www.habr.com