Platforma Enterprise 1c 8

Tipuri de date predefinite

Platforma 1C: Enterprise 8.0 permite dezvoltatorului să utilizeze diferite tipuri de date. Există multe tipuri de date care sunt definite la nivelul platformei. De exemplu, acestea sunt tipuri de date primitive, cum ar fi un șir, un număr, o dată și așa mai departe:







Platforma Enterprise 1c 8

De asemenea, există tipuri mai complexe de date. De exemplu, platforma acceptă un număr de tipuri care sunt colecții universale de valori: o matrice, o structură, o listă de valori, un arbore de valori etc.:

Platforma Enterprise 1c 8

În plus, platforma implementează tipuri specifice de date care implementează această sau acea funcționalitate a soluțiilor aplicate: un document text. document tabelar. Valorile stocate, Builder de rapoarte, Builder de interogări și multe altele:

Platforma Enterprise 1c 8

Tipurile de date generate în soluția aplicației

Cu toate acestea, împreună cu tipurile de date definite la nivel de platformă, o soluție de aplicație specifică poate utiliza tipuri de date unice care există numai în această aplicație. Iar platforma tehnologică 1C: Enterprise 8.0 va sprijini pe deplin lucrul cu aceste tipuri de date în același mod ca și cu tipurile definite la nivel de platformă.

De regulă, apariția de noi tipuri de date într-o soluție de aplicație implică utilizarea obiectelor de aplicație. La nivelul platformei tehnologice, se susțin mai multe clase de obiecte de aplicație, care, prin ele însele, nu pot fi utilizate într-o soluție de aplicație specifică. De exemplu, puteți lista astfel de clase de obiecte aplicate ca Directoare, Documente, Registre de date, Planuri de tipuri de caracteristici etc.







Pentru fiecare clasă de obiecte de aplicație, se definește funcționalitatea de bază corespunzătoare: tipurile de tabele de baze de date care trebuie create pentru stocarea datelor, formularele eșantion, obiectele standard de limbă, seturile de drepturi și așa mai departe.

Dezvoltatorul, atunci când creează o soluție de aplicație, nu are capacitatea de a folosi aceste clase în mod direct, dar poate adăuga un nou obiect de configurare soluției sale de aplicare. moștenind toate funcționalitățile unei clase:

De exemplu, un dezvoltator poate adăuga la cererea dumneavoastră soluție Nomenclator director nou, care va moșteni Directoarele de clasă, sau funcționalitatea unui nou document KassovyyOtchet care va moșteni funcționalitatea unei clase de documente.

Imediat după această adăugare, dezvoltatorul devine disponibil pentru noi tipuri de date, a căror compoziție este determinată de apartenența obiectului la o anumită clasă de obiecte de aplicație.

De exemplu, după crearea unui nou director de nomenclatură, vor fi disponibile următoarele tipuri de date:

În același timp, după crearea noului registru de acumulare a companiei de vânzări, compoziția noilor tipuri de date va fi diferită:

  • Registrul de gestionare a acumulării. Vânzarea companiei;
  • Registrul de acumulareCleaning. Vânzarea companiei;
  • Registrul de acumulare. Vânzarea companiei;
  • Registrul de acumulare a setului de înregistrări. Vânzarea companiei;
  • Registrul înregistrărilor de acumulare. Vânzarea companiei;
  • Registrul de acumulare a evidenței. Vânzările companiei.

Trebuie remarcat din nou că aceste tipuri de date nu sunt suportate de platformă încă de la început și există doar într-o soluție specifică de aplicații.

Un alt punct pe care să vă concentrați este cel mai simplu mod de a demonstra prin exemplu.

Să presupunem că sunt create două directoare noi în soluția aplicației. Nomenclatură și prețuri. În ciuda faptului că ambele obiecte au moștenit funcționalitatea clasei Directoare corespunzătoare și pentru ele a fost creată aceeași compoziție de tip de date în soluția aplicației, aceleași tipuri de date vor fi diferite tipuri de date. De exemplu, directorul DirectoryObject.Nomenclature și DirectoryObject.Prices sunt diferite tipuri de date.

Acest lucru se datorează faptului că dezvoltatorul poate adăuga la funcționalitatea sa de bază, moștenită de la clasa corespunzătoare, propriul său, special pentru fiecare obiect de configurare. De exemplu, cele două cărți de referință menționate mai sus pot conține părți de masă (acest lucru este moștenit din clasa Directoare). Cu toate acestea, pentru ghidul de prețuri, dezvoltatorul nu va crea nici o parte de masă, în timp ce pentru cartea de referință din Nomenclatură va crea, de exemplu, trei părți de masă. Evident, structura de stocare a datelor este de tip DirectoryObject. Nomenclatorul va fi semnificativ diferit de structura de stocare a datelor de tipul DirectoryObject.







Articole similare

Trimiteți-le prietenilor: