Ehi Habr!
In questo articolo inizieremo la storia di come funziona all'interno e quali tecnologie vengono utilizzate nel suo sviluppo.
Perché pensiamo che questo sia interessante? In primo luogo, perché la piattaforma 1C:Enterprise 8 è un'applicazione di grandi dimensioni (più di 10 milioni di righe di codice) in C++ (client, server, ecc.), JavaScript (client web) e, più recentemente, E . I grandi progetti possono essere interessanti almeno per la loro scala, perché problemi invisibili in una piccola base di codice emergono con tutta la loro forza in tali progetti. In secondo luogo, “1C:Enterprise” è un prodotto replicabile, “in scatola”, e ci sono pochissimi articoli su tali sviluppi su Habré. È sempre interessante anche sapere come è la vita in altri team e aziende.
Quindi iniziamo. In questo articolo forniremo una panoramica di alcune delle tecnologie utilizzate nella piattaforma e delineeremo il panorama, senza approfondire l'implementazione. In effetti, per molti meccanismi una storia dettagliata richiederebbe un articolo separato e per alcuni un intero libro!
Per cominciare, vale la pena decidere le cose di base: cos'è la piattaforma 1C:Enterprise e da quali componenti è composta. La risposta a questa domanda non è così semplice, perché il termine “Piattaforma” (per brevità la chiameremo così) si riferisce a un mezzo per sviluppare applicazioni aziendali, un ambiente runtime e strumenti di amministrazione. Si possono grosso modo distinguere i seguenti componenti:
- gruppo di server
- client “thin” in grado di connettersi al server tramite http e il proprio protocollo binario
- client per lavorare in un'architettura a due livelli con un database situato su un disco rigido o una cartella di rete
- cliente web
- strumenti di amministrazione del server delle applicazioni
- ambiente di sviluppo (noto come Configuratore)
- ambiente runtime per iOS, Android e Windows Phone (piattaforma mobile 1C)
Tutte queste parti, ad eccezione del web client, sono scritte in C++. Inoltre, c'è ciò che è stato recentemente annunciato , scritto in Java.
App native
C++03 viene utilizzato per sviluppare applicazioni native. Per Windows, come compilatore viene utilizzato Microsoft Visual C++ 12 (un profilo compatibile con Windows XP) e per Linux e Android - gcc 4.8, per iOS - clang 5.0. La libreria standard utilizzata è la stessa per tutti i sistemi operativi e compilatori: STLPort. Questa soluzione riduce la probabilità di errori specifici dell'implementazione STL. Stiamo attualmente pianificando la migrazione all'implementazione STL fornita con CLang, poiché STLPort è stato interrotto ed è incompatibile con la modalità abilitata per C++11 di gcc.
La base di codice del server è comune al 99%, quella del client al 95%. Inoltre, anche la piattaforma mobile utilizza lo stesso codice C++ di quella “grande”, sebbene la percentuale di unificazione sia leggermente inferiore.
Come la maggior parte degli utenti C++, non pretendiamo di utilizzare il 100% delle capacità del linguaggio e delle sue librerie. Quindi, praticamente non utilizziamo Boost e una delle funzionalità del linguaggio è il casting del tipo dinamico. Allo stesso tempo, utilizziamo attivamente:
- STL (nello specifico stringhe, contenitori e algoritmi)
- eredità multipla, incl. ereditarietà di implementazioni multiple
- Modelli
- eccezioni
- puntatori intelligenti (implementazione personalizzata)
Utilizzando l'ereditarietà multipla delle interfacce (classi completamente astratte), diventa possibile un modello a componenti, che verrà discusso di seguito.
Componenti
Per garantire la modularità, tutte le funzionalità sono suddivise in componenti, che sono librerie dinamiche (*.dll per Windows, *.so per Linux). Ci sono più di centocinquanta componenti in totale; ecco le descrizioni di alcuni di essi:
backend
Contiene il motore dei metadati della piattaforma
accnt
Oggetti che gli sviluppatori di applicazioni utilizzano per creare registrazioni contabili (piani contabili e registri contabili)
bsl
Motore di esecuzione del linguaggio incorporato
Nuke
Implementazione personalizzata dell'allocatore di memoria
dbeng8
Motore di database di file. Un semplice motore di database file server basato su ISAM, che include anche un semplice processore SQL
wbase
Contiene le classi di base e le funzioni per l'implementazione dell'interfaccia utente di Windows: classi finestra, accesso GDI, ecc.
La suddivisione in più componenti è utile sotto più punti di vista:
- La separazione promuove una migliore progettazione, in particolare un migliore isolamento del codice
- Da un set di componenti è possibile assemblare in modo flessibile diverse opzioni di consegna:
- Ad esempio, un'installazione thin client conterrà wbase, ma non avrà backend
- ma sul server wbase, al contrario, non lo sarà
- entrambe le opzioni ovviamente conterranno nuke e bsl
Tutti i componenti richiesti per questa opzione di avvio vengono caricati all'avvio del programma. Ciò, in particolare, è necessario per la registrazione delle classi SCOM, di cui parleremo di seguito.
SCOM
Per la scomposizione a un livello inferiore, viene utilizzato il sistema SCOM, una libreria simile nell'ideologia ad ATL. Per coloro che non hanno lavorato con ATL, elenchiamo brevemente le principali capacità e caratteristiche.
Per una classe SCOM appositamente progettata:
- Fornisce metodi factory che permettono di creare una classe da un altro componente conoscendone solo il nome (senza rivelarne l'implementazione)
- Fornisce un'infrastruttura di puntatori intelligenti per il conteggio dei riferimenti. Non è necessario monitorare manualmente la durata della classe SCOM
- Ti permette di scoprire se un oggetto implementa un'interfaccia specifica e convertire automaticamente un puntatore all'oggetto in un puntatore all'interfaccia
- Crea un oggetto di servizio che sia sempre accessibile tramite il metodo get_service, ecc.
Ad esempio, puoi descrivere una classe per leggere JSON (ad esempio, JSONStreamReader) nel componente json.dll.
Classi e istanze possono essere create da altri componenti; devono essere registrate nella macchina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Questa macro descriverà una speciale classe di registratore statico, il cui costruttore verrà chiamato quando il componente verrà caricato in memoria.
Successivamente, puoi crearne un'istanza in un altro componente:
IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));
A supporto dei servizi, SCOM offre un'infrastruttura aggiuntiva piuttosto complessa. Centrale è il concetto di processo SCOM, che funge da contenitore per l'esecuzione dei servizi (ovvero, svolge il ruolo di Service Locator) e contiene anche un collegamento alle risorse localizzate. Il processo SCOM è legato al thread del sistema operativo. Grazie a questo, all'interno dell'applicazione potrai ricevere servizi come questo:
SCOM_Process* process = core::current_process();
if (process)
return get_service<IMyService>(process);
Inoltre, commutando processi logici (SCOM) legati a un thread, è possibile ottenere applicazioni praticamente indipendenti dal punto di vista dello spazio informativo, in esecuzione all'interno dello stesso thread. Ecco come funziona il nostro thin client con un database di file: all'interno di un processo del sistema operativo ci sono due processi SCOM, uno associato al client e il secondo al server. Questo approccio ci consente di unificare la scrittura del codice che funzionerà sia sul database del file locale che nella versione “reale” client-server. Il prezzo per tale uniformità è alto, ma la pratica dimostra che ne vale la pena.
Sulla base del modello dei componenti SCOM, vengono implementate sia la logica aziendale che la parte di interfaccia di 1C: Enterprise.
Interfaccia utente
A proposito, sulle interfacce. Non utilizziamo controlli standard di Windows; i nostri controlli sono implementati direttamente sull'API di Windows. Per la versione Linux è stato realizzato un layer che funziona tramite la libreria wxWidgets.
La libreria di controlli non dipende da altre parti di 1C:Enterprise e viene utilizzata da noi in molte altre piccole utilità interne.
Nel corso degli anni di sviluppo di 1C:Enterprise, l'aspetto dei controlli è cambiato, ma un serio cambiamento nei principi si è verificato solo una volta, nel 2009, con il rilascio della versione 8.2 e l'avvento dei “moduli gestiti”. Oltre a cambiare l'aspetto, è cambiato radicalmente anche il principio del layout del modulo: si è rifiutato il posizionamento pixel per pixel degli elementi a favore del layout fluido degli elementi. Inoltre, nel nuovo modello, i controlli non funzionano direttamente con gli oggetti del dominio, ma con speciali DTO ().
Queste modifiche hanno reso possibile la creazione di un client Web 1C:Enterprise che replica la logica C++ dei controlli JavaScript. Cerchiamo di mantenere l'equivalenza funzionale tra thin client e web client. Nei casi in cui ciò non è possibile, ad esempio a causa di limitazioni dell'API JavaScript disponibile (ad esempio, la capacità di lavorare con i file è molto limitata), spesso implementiamo le funzionalità necessarie utilizzando 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 dei moduli gestiti viene utilizzata per creare un'interfaccia per applicazioni mobili sulla piattaforma 1C. Sui dispositivi mobili, la resa dei controlli viene implementata utilizzando tecnologie native del sistema operativo, ma per la logica del layout del modulo e la risposta dell'interfaccia viene utilizzato lo stesso codice della “grande” piattaforma 1C:Enterprise.
Interfaccia 1C su sistema operativo Linux
Interfaccia 1C su un dispositivo mobile
Interfaccia 1C su altre piattaforme
Interfaccia 1C sul sistema operativo Windows
Interfaccia 1C -client web
Open source
Sebbene non utilizziamo librerie standard per sviluppatori C++ sotto Windows (MFC, controlli da WinAPI), non scriviamo noi stessi tutti i componenti. Della biblioteca si è già parlato , 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 di posta (POP3, SMTP, IMAP)
- per analizzare i messaggi di posta elettronica
- per memorizzare i log degli utenti
- per l'internazionalizzazione
L'elenco potrebbe continuare.
Inoltre, utilizziamo una versione altamente modificata и quando si sviluppano test unitari.
Le librerie hanno richiesto un adattamento per essere compatibili con il modello organizzativo dei componenti SCOM.
La prevalenza di 1C rende la piattaforma un ottimo test di forza per le librerie in essa utilizzate. Una varietà di utenti e scenari rivela rapidamente errori anche nelle aree del codice utilizzate più raramente. Li correggiamo noi stessi e cerchiamo di restituirli agli autori della biblioteca. L'esperienza dell'interazione risulta essere molto diversa.
Sviluppatori и rispondere rapidamente alle richieste pull, ma la patch, ad esempio, in Non siamo mai riusciti a restituirlo.
conclusione
Nell'articolo abbiamo toccato diversi aspetti principali dello sviluppo della piattaforma 1C: Enterprise. Nell'ambito limitato dell'articolo, abbiamo toccato solo alcuni aspetti interessanti, a nostro avviso.
È possibile trovare una descrizione generale dei vari meccanismi della piattaforma .
Quali argomenti potrebbero interessarti nei prossimi articoli?
Come viene implementata la piattaforma mobile 1C?
Descrizione della struttura interna del web client?
O forse sei interessato al processo di selezione delle funzionalità per le nuove versioni, sviluppo e test?
Scrivi nei commenti!
Fonte: habr.com