Ciao, Habr!
In questo articolo inizieremo a raccontare come è strutturata all'interno e quali tecnologie vengono utilizzate per la sua realizzazione.
Perché riteniamo che questo sia interessante? Innanzitutto, perché la piattaforma '1C:Enterprise 8' è una grande applicazione (con oltre 10 milioni di righe di codice) scritta in C++ (client, server, ecc.), JavaScript (client web), e, da poco, anche . I grandi progetti sono interessanti almeno per la loro scala, poiché questioni nascoste in una piccola base di codice emergono in modo significativo in tali progetti. In secondo luogo, '1C:Enterprise' è un prodotto replicabile, 'in scatola', e ci sono pochi articoli su questo tipo di sviluppo su Habr. Inoltre, è sempre interessante scoprire come vivono in altri team e aziende.
Bene, cominciamo. In questo articolo daremo una panoramica di alcune tecnologie impiegate nella piattaforma, delineando il panorama senza immergerci troppo nella realizzazione. Infatti, per molti meccanismi, un racconto dettagliato richiederebbe un articolo a parte, e per alcuni, addirittura un intero libro!
Per iniziare, è importante chiarire le cose di base: cos'è la piattaforma '1C:Enterprise' e quali componenti la compongono. La risposta a questa domanda non è così semplice, poiché con il termine 'Piattaforma' (per brevità la chiameremo così) si intendono sia gli strumenti di sviluppo di applicazioni aziendali sia l'ambiente di esecuzione, oltre agli strumenti di amministrazione. Possiamo suddividerla in diverse componenti:
- cluster di server
- un 'client leggero' in grado di connettersi al server tramite http e un protocollo binario proprietario
- un client per lavorare in architettura a due livelli con un DB archiviato su disco rigido o in una cartella di rete
- client web
- strumenti di amministrazione del server delle applicazioni
- ambiente di sviluppo (conosciuto come Configuratore)
- ambiente di esecuzione per iOS, Android e Windows Phone (piattaforma mobile 1C)
Tutte queste parti, ad eccezione del client web, sono scritte in C++. Inoltre, è stato recentemente annunciato , scritto in Java.
Applicazioni native
Per lo sviluppo di applicazioni native si utilizza C++03. Su Windows viene impiegato Microsoft Visual C++ 12 (profilo compatibile con Windows XP), mentre su Linux e Android si usa gcc 4.8; per iOS si utilizza clang 5.0. La libreria standard utilizzata è unica per tutti i sistemi operativi e compilatori: STLPort. Questa soluzione riduce la probabilità di errori specifici dell'implementazione di STL. Attualmente stiamo pianificando il passaggio all'implementazione di STL fornita con CLang, poiché STLPort ha interrotto il proprio sviluppo ed è incompatibile con la modalità di supporto C++11 attivata in gcc.
La base di codice del server è comune per il 99%, mentre quella del client è comune per circa il 95%. Inoltre, anche la piattaforma mobile utilizza lo stesso codice C++ della versione 'grande', sebbene lì la percentuale di unificazione sia leggermente inferiore.
Come la maggior parte degli utenti C++, non pretendeniamo di utilizzare il 100% delle potenzialità del linguaggio e delle sue librerie. Infatti, non utilizziamo praticamente Boost e, tra le possibilità del linguaggio, solo il cast di tipo dinamico è raramente impiegato. D'altro canto, utilizziamo attivamente:
- STL (in particolare, stringhe, contenitori e algoritmi)
- ereditarietà multipla, inclusa l'ereditarietà multipla dell'implementazione
- template
- eccezioni
- puntatori intelligenti (implementazione proprietaria)
Grazie all'uso dell'ereditarietà multipla delle interfacce (classi completamente astratte) diventa possibile un modello a componenti, di cui parleremo più avanti.
Componenti
Per garantire la modularità, tutta la funzionalità è suddivisa in componenti, che si presentano come librerie dinamiche (*.dll per Windows, *.so per Linux). Ci sono più di cento componenti in totale; forniremo descrizioni di alcuni di essi:
backend
Contiene il 'motore' dei metadati della piattaforma
accnt
Oggetti che gli sviluppatori applicativi utilizzano per costruire contabilità (piani dei conti e registri contabili)
bsl
Motore di esecuzione del linguaggio integrato
nuke
Implementazione proprietaria di un allocatore di memoria
dbeng8
Motore di database file-based. Un semplice file-server per basi di dati, basato su ISAM, che include anche un semplice processore SQL
wbase
Contiene classi di base e funzioni per l'implementazione di interfacce utente Windows - classi delle finestre, accesso a GDI, ecc.
La suddivisione in numerose componenti è utile da diversi punti di vista:
- La separazione favorisce un migliore design, in particolare una migliore isolamento del codice
- Dal set di componenti è possibile assemblare diverse varianti di fornitura:
- Ad esempio, l'installazione del thin client conterrà wbase, ma non conterrà il backend
- mentre sul server wbase, al contrario, non ci sarà
- entrambi le varianti conterranno, ovviamente, nuke e bsl
Tutti i componenti necessari per questa variante di avvio vengono caricati all'avvio del programma. Questo è, in particolare, necessario per la registrazione delle classi SCOM, di cui si parlerà più avanti.
SCOM
Per la decomposizione a un livello più basso si utilizza il sistema SCOM, simile nella filosofia alla libreria ATL. Per coloro che non hanno lavorato con ATL, elencherò brevemente le principali funzionalità e caratteristiche.
Per la classe SCOM appositamente formattata:
- Fornisce metodi factory che consentono di creare una classe a partire da un'altra componente conoscendo solo il suo nome (senza rivelare l'implementazione)
- Fornisce un'infrastruttura di smart pointer con conteggio dei riferimenti. Non è necessario monitorare manualmente la durata di vita della classe SCOM
- Permette di verificare se un oggetto implementa un'interfaccia specifica e di convertire automaticamente un puntatore a oggetto in un puntatore all'interfaccia
- Creare un oggetto-servizio, sempre accessibile tramite il metodo get_service e così via.
Ad esempio, è possibile descrivere nella componente json.dll una classe per la lettura di JSON (ad esempio, JSONStreamReader).
Le classi, gli oggetti possono essere creati da altre componenti devono essere registrati nella macchina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Questa macro descriverà una speciale classe statica registratore, il cui costruttore sarà chiamato al caricamento della componente in memoria.
Dopo ciò, è possibile creare la sua istanza in un'altra componente:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
Per il supporto dei servizi, SCOM offre un'infrastruttura aggiuntiva, abbastanza complessa. Il concetto centrale è quello del processo SCOM, che funge da contenitore per i servizi in esecuzione (cioè funge da Service Locator) e include anche il collegamento alle risorse localizzabili. Il processo SCOM è legato al thread del sistema operativo. Grazie a ciò, all'interno dell'applicazione è possibile ottenere i servizi in questo modo:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Inoltre, imparando a commutare i processi logici (SCOM) legati al flusso, è possibile ottenere applicazioni praticamente indipendenti dal punto di vista dello spazio informativo, che operano all'interno di un unico flusso. Questo è il funzionamento del nostro thin client che lavora con il database file-based: all'interno di un processo del sistema operativo sono presenti due processi SCOM, uno legato al client e l'altro al server. Questo approccio consente di uniformare la scrittura del codice, che funzionerà sia con un database file locale che nella vera variante client-server. Il prezzo di tale uniformità sono i costi generali, ma la pratica dimostra che ne vale la pena.
La logica di business e la parte dell'interfaccia di 1C: Enterprise sono implementate sulla base del modello a componenti SCOM.
Interfaccia utente
A proposito di interfacce. Non utilizziamo i controlli standard di Windows, i nostri elementi di controllo sono implementati direttamente sull'API di Windows. Per la versione Linux è stata creata un'interfaccia che funziona attraverso la libreria wxWidgets.
La libreria di elementi di controllo non dipende da altre parti di "1C:Enterprise" ed è utilizzata anche in altre piccole utility interne.
Nel corso degli anni di sviluppo di 1C:Enterprise, l'aspetto dei controlli è cambiato, ma un cambiamento significativo nei principi si è verificato solo una volta, nel 2009, con il rilascio della versione 8.2 e l'introduzione delle "form controllate". Oltre al cambiamento dell'aspetto, il principio di composizione dei moduli è stato fondamentalmente rivisitato: si è abbandonata la posizionamento pixel-per-pixel delle componenti a favore della composizione a flusso. Inoltre, nel nuovo modello gli elementi di controllo non interagiscono direttamente con gli oggetti di dominio, ma con speciali DTO ().
Questi cambiamenti hanno permesso di creare il client web di "1C:Enterprise", che replica la logica dei controlli C++ su JavaScript. Ci sforziamo di mantenere l'equivalenza funzionale tra il thin client e il web client. Nei casi in cui ciò non sia possibile, ad esempio a causa delle limitazioni nell'API di JavaScript (ad esempio, le possibilità di lavorare con file sono molto limitate), spesso realizziamo la funzionalità necessaria tramite estensioni del browser scritte in C++. Attualmente supportiamo Internet Explorer e Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows e Linux) e Safari (MacOS).
Inoltre, la tecnologia delle forme gestite viene utilizzata per creare l'interfaccia delle applicazioni mobili sulla piattaforma 1C. Su dispositivi mobili, il rendering dei controlli viene implementato utilizzando tecnologie "native" per il sistema operativo, ma già per la logica di composizione della forma e per la reazione dell'interfaccia viene utilizzato lo stesso codice della "grande" piattaforma "1C:Enterprise".
Interfaccia 1C su OS Linux
Interfaccia 1C su dispositivo mobile
Interfaccia 1C su altre piattaforme 
Interfaccia 1C su OS Windows
Interfaccia 1C — client web
Open source
Anche se non utilizziamo le librerie standard per sviluppatori C++ su Windows (MFC, controlli di WinAPI), non scriviamo tutti i componenti da soli. È stata già menzionata la libreria , e usiamo anche:
- per lavorare con HTTP e FTP.
- per lavorare con la crittografia e stabilire connessioni TLS
- per l'analisi XML
- per lavorare con i protocolli e-mail (POP3, SMTP, IMAP)
- per l'analisi dei messaggi di posta elettronica
- per memorizzare i log delle attività degli utenti
- per l'internazionalizzazione
La lista può continuare.
Inoltre, utilizziamo versioni fortemente modificate di e per sviluppare unit test.
Le librerie hanno richiesto un'adattamento per essere compatibili con il modello SCOM dell'organizzazione dei componenti.
La diffusione di 1C rende la piattaforma un ottimo banco di prova per le librerie utilizzate. La varietà di utenti e scenari individua rapidamente gli errori anche nelle parti di codice più raramente usate. Li correggiamo internamente e cerchiamo di restituirli agli autori delle librerie. L'esperienza di interazione è molto varia.
Sviluppatori e rispondono rapidamente ai pull request, ma il patch, ad esempio, in non siamo riusciti a restituirlo.
Conclusione
Nell'articolo abbiamo toccato alcuni aspetti principali dello sviluppo della piattaforma "1C: Enterprise". In uno spazio limitato, abbiamo toccato solo alcuni aspetti che riteniamo interessanti.
Una panoramica sui vari meccanismi della piattaforma può essere vista .
Quali temi sarebbero interessanti per voi nei prossimi articoli?
Come è stata realizzata la piattaforma mobile 1C?
Descrizione della struttura interna del client web?
Oppure, forse, vi interessa il processo di selezione delle funzionalità per i nuovi rilasci, sviluppo e testing?
Scrivete nei commenti!
Fonte: habr.com
