| CATEGORII DOCUMENTE |
Alin Flaidar
Trei ani de la aparitia ultimei versiuni de Turbo Pascal au fost, categoric, prea mult. Doar fidelii Pascal-ului au mai rezistat tentatiei Visual Basic sau ofertei C++. Pentru a-si recaștiga adeptii, Borland face o miscare spectaculoasa si riscanta. Noul stil de dezvoltare a aplicatiilor propus de Delphi lasa sa se intrevada o perspectiva terifianta si foarte probabila a viitorului programarii: vom pluti printre sute de obiecte din care ne vom alege vizual caramizile constituente ale aplicatiei. Utilizatorii vor redeveni - ca la inceputuri - dezvoltatori, iar programatorii veritabili vor scrie biblioteci de obiecte integrate in sistemul de operare.
Pana la impunerea Windows 3.0, Turbo Pascal devenise un standard de factor al dezvoltarii facile de programe pentru DOS. Viteza mare de compilare-linkeditare, biblioteca de sistem bogata in functii, limbajul simplu si cu verificare stricta a tipurilor faceau din el o scula foarte productiva la nivelul cerintelor de atunci. Schimbarile bruște de tehnologie care au zguduit lumea simpla single-task si in mod real de adresare a DOS-ului au prins pe picior greșit dezvoltatorii Turbo Pascal-ului. Incercarile de a promova o interfata obiectuala pentru DOS (Turbo Vision) si suportul limitat oferit pentru DOS -mod protejat (un DPMI pe 16 biti) au demonstrat ca Borland a ales gresit calea de dezvoltare a compilatorului.
Versiunea Windows nu era consecventa cu modul facil de programare practicat de majoritatea utilizatorilor de Turbo Pascal. Obligativitatea utilizarii de pointeri, type-casting si definirii de noi obiecte pentru orice functie specifica au speriat programatorii care erau foarte fericiti pana atunci utilizand numai variabile statice si locale.
Object Windows nu scutea suficient programatorul de contactul cu interfata urata si incalcita Windows API, iar interactiunea directa cu mesajele Windows nu elimina necesitatea scrierii de cod care sa compenseze neajunsurile si sa ocoleasca fundaturile Windows. In ciuda unei remarcabile implementari a lui Object Pascal , Borland continua sa furnizeze biblioteci obiectuale numai pentru construirea de interfete si prea putin pentru manipularea structurilor de memorie si a bazelor de date, in timp ce devenise evident ca realizarea interfetelor cu utilizatorul era o treaba de design vizual. Urmarea a fost ca programatorii nepretentiosi au migrat spre Visual Basic in timp ce profesionistii au optat pentru C++, de la care Pascal imprumutase deja prea mult.
Venise timpul pentru o cotitura in strategia firmei si, dupa debarcarea lui Philippe Kahn, noul mediu de dezvoltare Pascal al firmei a fost substantial restructurat, dotat cu o remarcabila biblioteca de obiecte si orientat spre realizarea rapida de aplicatii.
Borland a invatat bine lectia lui Visual Basic care a aratat clar ce asteapta dezvoltatorii in materie de producere rapida a unei aplicatii (si nu care este directia de evolutie a limbajelor de programare).
Daca la inceputurile programarii Windows raportul intre durata de realizare a interfetei cu utilizatorul si cea de implementare a functionalitatii propriu-zise a aplicatiei era de 20:1, biblioteci precum OWL, MFC sau Zinc au redus raportul la 3:1, acum dezvoltatorul modern pretinde sa nu petreaca mai mult de 5-10% din timp desenand interfete. Migrarea aplicatiilor de baze de date spre Windows si arhitecturi client-server au impus aparitia extensiilor de baze de date in mediul de dezvoltare vizuala. In mod logic, au urmat obiectele cele mai frecvent utilizate astfel incat mediile RAD curente sunt destul de complexe si heterogene, exceland intr-un aspect sau altul dar nesatisfacand nici unul toate dezideratele: compilator generator de cod executabil real, arhitectura deschisa, limbaj obiectual complet, flexibilitate a relatiei cod - obiecte vizuale. Sisteme precum Visual Basic si Power Builder șchioapata la capitolul limbaj in timp ce expertii din Borland C++ si vrajitorii lui Visual C++ sunt exemple de cum nu trebuie sa functioneze un mediu de dezvoltare vizuala.
Un compilator exceptional de rapid si un limbaj obiectual evoluat si revazut capabil sa creeze executabile independente si module DLL au creat premizele devenirii RAD a mediului Turbo Pascal. Conceperea unui mediu vizual de dezvoltare deosebit de puternic si elastic bazat pe componente vizuale ca obiecte reutilizabile, dezvoltarea unei biblioteci de aproape o suta de componente de baza, introducerea de componente cu suport de baze de date locale si partajate in retea ca si de arhitecturi client-server au completat ceea ce in final s-a chemat Delphi.
Sintagma RAD este cat se poate de reala: doar cateva minute pentru producerea unei forme de editare date in cod executabil self-consistent.
Turbo Pascalul renaste din cenusa si are toate sansele sa-si recastige adeptii iar Borland Intl. actionarii.
Primul contact cu Delphi a fost - indiscutabil - deconcertant. Un toolbar, un spatiu de desen, mi-au trebuit cinci minute sa descopar editorul de cod si jumatate de ora sa localizez programul principal - acum botezat Delphi project.
Parea de neconceput sa incepi un program desenand, asa incat m-am grabit sa ma asigur ca Delphi compileaza mai vechile aplicatii Borland Pascal 7.0. Nu a fost prea simplu, dar dupa ce am modificat referintele la unitatea Win31 din clauzele uses si am rebotezat o variabila ce se numea Result - acum nume rezervat pentru rezultatul returnat de o functie, Delphi a compilat fara probleme in 3 secunde cele 11.000 de linii ce alcatuiau o aplicatie de anvergura medie. Codul rezultat parea ceva mai mare decat cel generat de BP 7 dar a revenit la normal dupa ce am eliminat optiunea Pentium safe FDIV care determina link-editarea unei biblioteci proprii de virgula mobila. Aparent, Borland nu a imbunatatit compilatorul sau clasic de 16 biti decat sub aspectul vitezei de compilare. Am fost dezamagit totusi ca - nici cu Delphi - Object Pascal nu a evoluat spre cod pe 32 de biti, chiar daca principalul concurent se numeste acum Visual Basic.
Cu fiecare versiune de compilator, Borland a propus o noua solutie si a promis o crestere a productivitatii. La vremea lor Turbo Vision si Object Windows au fost revolutionare si au necesitat o revedere a conceptiilor despre programare si am sperat ca Delphi nu va fi mai pretentios. Din nefericire autorii lui au vizat atragerea neinitiatilor si au facut prea putin pentru readaptarea veteranilor. Mediul si chiar limbajul sunt o discontinuitate evidenta fata de produsele anterioare si promisiunea compatibilitatii nu este insotita si de cea a reutilizarii codului mai vechi.
Obisnuit cu generatoare clasice de cod gen ProtoGen sau Application/Class expert din BC++ ma asteptam sa intalnesc ceva similar, cu o succesiune clasica dezvoltare vizuala - generare cod - modificare si scriere de cod specific, axata pe derivarea de noi clase pentru fiecare functie specifica.
In Delphi insa, editorul vizual este strans integrat cu editorul de cod. Acestea sunt permanent sincronizate si, chiar daca relatia nu este in ambele sensuri, conceptul este cel de lucru alternativ in ambele planuri, cu accent pe editorul vizual care piloteaza scrierea procedurilor de cod specific ca rutine de tratare a evenimentelor.
Entitatile cu care opereaza editorul vizual corespund la obiecte de tip component in codul Pascal. Numai clase neabstracte derivate din tipul TComponent pot fi integrate in biblioteca de componente a editorului vizual.
Aplicatia este vazuta ca un ansamblu de forme - ferestre si dialoguri clasice Windows - care ocupa un rol central in arhitectura programelor. Forma este entitatea care cuprinde celelalte componente si al carei scop global permite o viziune completa a interactiunii acestora si faciliteaza obtinerea unei functionalitati specifice. Reflectarea formei in cod se face ca o unitate distincta (Pascal unit) care declara in partea de interfata o clasa de tip TForm avand drept campuri obiectele componente. Initial noua forma nu include metode specifice, dar contine o apreciabila doza de functionalitate prin cele cateva zeci de metode private si publice mostenite de la TForm ca si prin comportamentul standard al obiectelor componente care asigura aspectul si controlul interactiunilor dintre componente. In faza aceasta forma este perfect compilabila si utilizabila chiar fara vreo linie suplimentara de cod. Cum din unitatea asociata de cod nu reiese nimic, este firesc sa te intrebi cum sunt incorporate definitiile proprietatilor, pozitiilor componentelor si formei, intr-un cuvant, desenul? Raspunsul este dat de asocierea fișierului unitate cu un fisier de tip resursa binara Windows (cu extensie DFM) care se link-editeaza in codul executabil si are acelasi rol ca si resursele standard dar care nu contine dialoguri, imagini bitmap sau icon-uri, ci un format special incarcat de constructor la crearea obiectului forma.
Componentele 'vizibile' pot fi controale clasice Windows gen butoane, editoare, liste de selectie, etc. dar si o varietate de controale sofisticate cu functii noi oferite in standard de Delphi. Tot vizibile sunt si componentele de tip dialog care automatizeaza functiile comune de tip selectie de fișier, font, culoare, etc. In spatele interfetei cu utilizatorul de pe forma se gaseste artileria grea - componentele invizibile care confera functionalitate aplicatiei din care cele mai semnificative sunt obiectele de acces la bazele de date. Un avantaj remarcabil il confera lui Delphi capacitatea de a produce si integra in biblioteca componente complet noi sau derivate din tipurile existente, ca si controale in format VBX 1.0.
Particularizarea unui component se face prin modificarea vizuala a proprietatilor acestuia. Inspectorul de proprietati permite specificarea aspectului unei forme sau al unui control vizibil din forma facilitand spre exemplu setarea culorii, a unui font specific, etc. Mult mai spectaculoase sunt proprietatile care descriu interactiunea componentelor cu alte componente sau cu structuri de date in memorie sau pe disc, diferentierea comportamentului in interactiune cu utilizatorul. Toata aceasta informatie se stocheaza in intregime in resursa si permite, spre exemplu, conceperea unei machete sofisticate de introducere a datelor fara generarea vreunei metode specifice in sectiunea de cod.
Celor carora manipularea obiectelor prin proprietati in faza de dezvoltare li se pare fireasca le reamintesc ca nu au de-a face nici cu Basic, nici cu Paradox sau Fox, in care proprietatile se interpreteaza precum intregul cod de altfel, cu penalizarile corespunzatoare de performanta si consum de resurse. Integrarea conceptului de proprietate intr-un limbaj compilat prin excelenta este un pas remarcabil intr-o lume in care modificarea functionala a unui obiect nu era posibila decat in timpul executiei (la runtime), prin apeluri de metode !
Exigentele de mediu de dezvoltare rapida de aplicatii presupun mai mult insa decat asamblarea aplicatiei din caramizi standard. Cand si unde se scrie codul care determina functiile specifice ale aplicatiei?
Nimeni si nimic nu impiedica programatorul sa scrie in cea mai clasica maniera unitati intregi de obiecte si functii Pascal, ce pot fi integrate firesc in proiectul Delphi. Mediul Delphi nu piloteaza dezvoltatorul in programarea clasica algoritmica si nici nu dispune de un class expert care sa faciliteze dezvoltarea de noi obiecte. Delphi gestioneaza utilizarea de obiecte.
Cand un component intalneste o conditie deosebita - spre exemplu, un click de mouse pe un component-buton sau actualizarea unei inregistrari pe disc pentru un component-tabela - acesta genereaza un eveniment care se traduce prin apelul unei metode dedicate a formei care contine obiectul, al carei scop este executarea unei functii specifice. Evenimentele care pot fi generate de un component sunt accesibile in editorul vizual, la fel ca si proprietatile: un dublu click pe un eveniment din lista si Delphi selecteaza sau genereaza automat o metoda specifica pentru forma si plaseaza cursorul in editorul de cod acolo unde trebuie scris sau exista deja codul specific evenimentului.
Aceasta tehnica de notificare a formei de catre component la aparitia unui eveniment reprezinta o modalitate eleganta de delegare a responsabilitatii reactiei catre forma, singurul obiect care detine o perspectiva globala si este in masura sa actioneze corespunzator.
Imaginati-va cum era rezolvata pana acum urmatoarea situatie in limbajele obiectuale cele mei evoluate: un click pe un buton trebuie sa determine inserarea unui text dintr-un editor intr-o lista de selectie (listbox). Din clasa TButton trebuie derivata o noua clasa avand o metoda ButtonClick care reactioneaza la click, in care se acceseaza prin typecasting pe campul Parent campurile editor si lista ale formei-parinte pentru efectuarea operatiunii. Pentru comparatie, in Delphi nu este necesara instantierea unei noi clase de buton si nici un typecasting complicat pentru ca forma detine in scopul sau accesul la toate componentele; ajunge legarea unei metode a formei de evenimentul butonului.
Practic, cu exceptia formelor pe care oricum le intretine Delphi, nu este necesara definirea de noi clase pentru realizarea unei aplicatii respectabile. Coșmarul crearii de clase noi s-a topit. Portile sunt larg deschise fanilor Visual Basic-ului.
Imi amintesc recenzia primului Turbo Pascal for Windows din Dr. Dobbs, in finalul careia Jeff Dunteman rupea orice speranta eventualilor programatori care se vedeau rescriind Excel-ul intr-un weekend. Ei bine, un Excel nu, dar un program de calcul tabelar, multi-document, cu suport OLE a devenit perfect fezabil in cateva zile si sute de kilobytes.
Care este insa pretul care a trebuit platit pentru a obtine un mediu capabil de o asemenea performanta? Pare greu de imaginat, dar Borland a considerat ca gatuirea productivitatii se producea chiar in clasicul, batranul, productivul Pascal. Noutatile introduse in limbaj fac ca un batran pascalist care le supravietuieste sa fie perfect adaptabil la viata subacvatica a omenirii din secolul 34. Pentru menajarea lui sa precizam din start ca include inca sintaxa, cuvintele rezervate si functiile standard ale vechiului Pascal.
Evident, cele mai dramatice schimbari au fost operate chiar la nivelul obiectual. Noul tip de obiect, declarat acum folosind cuvantul rezervat class, nu poate exista decat ca pointer si instantiat dinamic in heap prin apelarea constructorului. Urmare a faptului ca toate obiectele sunt acum pointeri, s-a eliminat necesitatea dereferentierii lor explicite prin simbolul ^. Noile obiecte sunt referite astfel NewObject.Field, echivalent cu vechiul model OldObject^.Field. O inovatie gratuita poate, mirosind a concesie pentru 'vizual-bazicari'.
A fost introdus stramosul comun implicit al tuturor claselor, TObject, care asigura polimorfismul obiectelor la cel mai jos nivel.
Campurile componente si metodele gestionate de editorul vizual sunt plasate in sectiunea implicita a obiectului forma, fiind obligatorie includerea explicita in sectiunile public si private a campurilor si metodelor declarate de programator.
Noi tipuri de sectiuni au aparut in declararea tipului de obiect. Protected permite accesul la campuri si metode declarate astfel numai obiectelor descendente, delimitand astfel interfata obiectului intre utilizatori si dezvoltatori de obiecte.
O remarcabila noutate este declaratia published care extinde accesul la campuri si metode ale unui obiect in afara modulului executabil, facand astfel posibil exportul de interfete de obiecte catre alte aplicatii. O initiativa similara din partea Microsoft ne-ar fi scutit de interfata inter-aplicatii stupida si lacoma de resurse numita OLE! Cea mai evidenta utilitate a publicarii obiectelor este posibilitatea editorului vizual de a avea acces la numele si tipurile proprietatilor exportate de obiectele componente rezidente in biblioteca dinamica de componente (un modul DLL numit complib.dcl). Modul de acces la obiecte publicate nu este specificat de Borland in documentatia standard care insoteste pachetul dar este de asteptat sa fie disponibil in documentatia limbajului Object Pascal sau via Internet.
Care este secretul implementarii proprietatilor obiectelor? Cum este posibil sa scrii Editor.Visible := true si campul de editare sa apara pe forma? Miroase a interpretor de cod! In fapt lucrurile sunt mult mai simple. Proprietatea Visible este declarata cu doua metode private asociate, de citire si scriere a valorii proprietatii. Intern, inaintea compilarii, preprocesorul substituie codul de mai sus cu un apel de metoda Editor.Show(true), care se ocupa de bucataria afisarii controlului. Proprietatile pot fi si vectori: elocvent este accesul la pixelii de pe device context cu proprietatea Canvas.Pixels[X,Y].
Utilizarea metodelor unei clase s-a diversificat cu doua noi concepte. Metodele de clasa se declara cu prefixul class si sunt metode ale tipului de obiect si nu ale unei instante specifice a tipului respectiv de obiect. Se poate apela o astfel de metoda fara a mai fi nevoie sa se instantieze un obiect.
Pentru implementarea conceptului de eveniment a fost necesara crearea notiunii de pointer de metoda, un tip procedural special care permite apelarea unei metode de obiect din afara obiectului si fara a se utiliza o referinta la obiect. Evenimentul unui component este de fapt un pointer la metoda formei-parinte ce contine cod specific de tratare a evenimentului respectiv.
Oarecum de asteptat este inovatia transmiterii de vectori deschisi (open arrays) ca parametri de functie sau procedura. Constructia vectorului se face acum chiar in apelul de procedura cu specificarea unui numar variabil de elemente. Borland a plusat permitand chiar specificarea de elemente de tip diferit in vector, facilitand astfel apelul de rutine de formatare de string-uri si, cu putina imaginatie chiar apeluri de functii in stil C.
Lista schimbarilor nu se incheie aici si poate fi consultata in caseta 'Schimbari in Object Pascal'. Nu voi conchide cu epitaful Pascal-ului pentru ca, ceea ce de mult era de asteptat, handicapul ce transa orice disputa Pascal versus C, ultima bariera a cazut in cele din urma:
Importanta tratarii exceptiilor este covarsitoare si numai cei ce s-au aventurat in dezvoltarea unui proiect de anvergura fara a se asigura astfel au gustat din amaraciunea loviturilor pe la spate, gen depasire de virgula mobila ce antreneaza pierderea integrala a datelor iar daca au incercat sa-si ia masuri de protectie codul de validare a parametrilor si rezultatelor tindea sa-l depaseasca pe cel propriu-zis si antrena noi bug-uri.
Posibilitatile deschise de Delphi fac ca arhitectura unei aplicatii sa devina foarte complexa si probabilitatea survenirii de exceptii sa creasca exponential, mai ales in medii de baze de date.
Tratarea exceptiilor se face conform unui concept hibrid intre sistemul clasic de tratare structurata a exceptiilor si recunoasterea exceptiilor ca tipuri de obiecte. Codul susceptibil sa intalneasca o eroare se include intr-un bloc de protectie la care se ataseaza un alt bloc cu cod de tratare a exceptiilor suspectate. Blocul de tratare poate fi completat cu unul de terminare, tipic cu cod de facut curatenie, care primeste controlul dar nu stinge exceptia. Exceptiile sunt diferentiate ca obiecte distincte derivate din tipul Exception si mostenesc codul necesar afisarii unui mesaj formatat si conectarii cu un help topic. Blocurile de protectie pot fi imbricate si controlul executiei revine la nivelul la care blocul de tratare recunoaste si intercepteaza tipul respectiv de exceptie.
Cea mai frecventa utilizare a blocurilor de protectie-tratare a exceptiilor se intalneste cand se doreste protejarea alocarii de resurse. Adesea aparitia unei exceptii poate impiedica atingerea codului in care se efectueaza eliberarea memoriei, inchiderea de fisiere sau dealocarea de resurse Windows, cu consecinte imprevizibile pentru integritatea datelor sau stabilitatea sistemului. Includerea acestui cod - botezat cleanup code - intr-un bloc de terminare garanteaza executia lui indiferent de aparitia exceptiei.
Invocarea unei exceptii este cea mai buna metoda si adesea singura pentru a 'scapa' din ramura de executie curenta. Spre exemplu, daca in metoda ce trateaza evenimentul BeforePost al unui obiect-tabela se invoca o exceptie, actualizarea inregistrarii curente in tabela este anulata.
Tratarea exceptiilor nu este numai pentru programatorii profesionisti. Chiar daca este complet ignorata de dezvoltator, protectia la exceptii incorporata in componentele din care s-a asamblat aplicatia blocheaza orice exceptie survenita fie din conditii externe, fie din erori de programare. Pur si simplu aplicatia nu crapa. Isi revine pana si din erori serioase precum General Protection Fault !
Paradoxul asocierii unui compilator cu un sistem de gestiune a bazelor de date este numai aparent. Desi un mediu RAD nu este obligatoriu si un mediu de dezvoltare de aplicatii de baze de date, nealinierea la cererea principala a pietii poate scoate din competitie cel mai performant sistem. Borland dispunea nu numai de atu-ul unui compilator remarcabil ci si de o tehnologie avansata de baze de date, completata in ultima vreme cu dezvoltarea Interbase SQL si achizitionarea lui ReportSmith. Iar cum produsul in care a investit cel mai mult se numeste Paradox, cu ce altceva decat Paradox putea sa semene cel mai mult suportul de baze de date al lui Delphi!?
Delphi, intrinsec, nu are incorporat nici un fel de suport de baze de date. Totusi, componentele specializate in acces la baze de date livrate in standard sunt atat de complete incat transforma efectiv dezvoltarea unei forme intr-o familiara editare de macheta cu tabele si query-uri in cele mai variate relatii de one-to-many, many-to-many, one-to-many-to-many-toetc., cu controale din cele mai diverse, de la campuri de editare cu validare la campuri calculate, de la tabele cu editare in-place la campuri lookup combo box sau list box. Nu lipseste nici clasicul navigator cu butoane de inainte-inapoi, stergere, inserare, actualizare, etc.
Dezvoltatorul detine un control total asupra interactiunilor dintre utilizator si baza de date prin intermediul unui set complet de evenimente generate de obiecte dataset (tabele si query-uri) si datasource (interfata intre dataset si campurile de editare). Exista astfel posibilitatea de a efectua validari inainte de actualizarea modificarilor in tabela, de a primi controlul inaintea inserarii sau stergerii unei noi inregistrari sau la prima tentativa de modificare a inregistrarii curente. Iar lista de posibilitati ramane deschisa.
Cel mai bine se vor simti programatorii de Paradox care vor regasi aceeasi filozofie in manipularea tabelelor prin operatiuni familiare precum Insert, Edit, Cancel, Post (Do_It), Next, First, Last, etc. Campurile unei inregistrari sunt accesibile ca obiecte componente distincte prin intermediul editorului de campuri al tabelei, existand tipuri distincte pentru fiecare format, inclusiv imagine, memo sau cimp binar (BLOB). Adesea, singura operatiune cu campuri efectuata prin program este atribuirea sau citirea valorii unui camp. Accesul se face prin intermediul proprietatii Value si mentinerea sincronizarii campului cu controlul de editare asociat sau cu tabela se face automat prin metodele mostenite.
In spatele scenei se gaseste o implementare deosebit de puternica a accesului la baze de date. Obiectul tabela trateaza in mod unitar atat o tabela Paradox sau dBase cat si una SQL. Nu este necesara nici un fel de modificare in cod sau in proprietatile tabelei pentru a muta o aplicatie de pe o baza de date locala pe o baza de date echivalenta de pe un server SQL! Nu exista de asemenea nici o limitare in lucrul simultan cu tabele provenind din surse diferite. Pe aceeasi forma pot coexista tabele SQL si un spreadsheet Excel provenind dintr-o sursa ODBC. Remarcabila este si aducerea la un numitor comun a diverselor specii de index, programatorul utilizand transparent un index secundar Paradox, un index DBase sau unul SQL.
Intrucat editoarele de componente nu dispun de facilitati de creare, editare sau interogare de baze de date in scopuri de testare a aplicatiilor, Delphi este insotit de Database Desktop - un Paradox miniatural capabil sa creeze si restructureze tabele Paradox si DBase dar si SQL, fara capabilitati de forme si rapoarte - evident.
Doar utilizarea tabelelor, chiar cu filtre si legate in relatii complexe, nu mai satisface adesea nici macar in scopuri de editare. Iar a interoga navigand prin tabele si testand relatii a devenit nu numai desuet si neproductiv dar chiar generator de bug-uri.
Utilizarea obiectele tip TQuery deschide perspective remarcabile catre cele mai diverse scheme de prelucrare sau editare a datelor. Query-urile sunt in esenta obiecte de executie a unei comenzi SQL asupra unor tabele putand proveni din surse eterogene, Paradox, DBase, ODBC sau servere SQL diferite. Fiind un descendent al tipului TDataset, query-ul are numeroase trasaturi comune cu tabela, putand fi integrat in relatii, navigat, chiar editat in anumite conditii cand se comporta ca un dynaset si actualizeaza tabelele de provenienta a datelor. Evident, comenzile SQL admit variabile care permit schimbarea dinamica a rezultatelor query-ului si chiar legarea query-ului de valori din inregistrarea curenta a altei tabele sau query.
Un obiect specializat in copierea si adaugarea de dataset-uri, TBatchMove, permite inlantuirea query-urilor atunci cand nu se poate ajunge la rezultatul dorit printr-o singura interogare SQL.
Dezvoltatorii nefamiliari cu SQL pot folosi Database Desktop pentru a construi vizual un query-by-example pe care il pot traduce apoi in comanda SQL si integra in obiectul query, daca nu sunt cumva fericitii posesori ai versiunii client-server care include un editor vizual de query-uri. Nu orice QBE se poate traduce in SQL si invers.
Utilizarea de query-uri reduce dramatic timpul de dezvoltare a unei baze de date si creaza premize spre migrarea acesteia spre suport SQL. Folosirea lui pe baze de date locale simplifica dezvoltarea dar abuzul se plateste scump. Astfel, crearea un obiect query necesita cam 100 KBytes de memorie, in timp ce un obiect tabela se multumeste cu cativa KBytes.
Cine este responsabil de interpretarea si executia query-ului, ca si de acces la baze de date in general? Borland si-a bazat toate produsele, de la Paradox la Delphi pe al sau Borland Database Engine (o implementare a standardului IDAPI - alternativa viabila la ODBC-ul lui Microsoft). Prin BDE este posibil accesul atat la surse native cum sunt Paradox si dBase precum si la conexiuni ODBC, pentru care interpreteaza si executa comenzile SQL, cat si la servere SQL, carora le transmite cererile SQL si optimizeaza modul de acces la rezultate. Din punct de vedere al performantei pe baze de date locale, driver-ele native Paradox si DBase sunt net mai rapide decat cele similare disponibile prin ODBC, astfel incat acesta din urma ramane doar ca alternativa de conectare la formate mai ciudate de tabele.
Dornica sa apelez direct functii BDE am descoperit - nedocumentata bineinteles - interfata de programare BDE (fisierele dbiprocs.int, dbierrs.int, dbitypes.int). Desi cautam numai o functie de actualizare a cache-ului pe disc am descoperit stupefiata functii de un nivel foarte inalt de operare cu query-uri, seturi de date, tranzactii, operatiuni de tip batch, stabilire de relatii, sortare, s.a.m.d. Se explica astfel capabilitatile remarcabile ale obiectelor tabela si query din Delphi, care nu sunt decat simple impachetari obiectuale ale functionalitatii unui motor de baze de date foarte avansat. Aplicatiile Delphi au in spate performanta nativa a Paradox-ului si DBase-ului for Windows.
Desi oferta este covarsitoare, Borland pluseaza din nou integrand si Local Interbase Server - o versiune locala de server SQL, mono-utilizator si multi-instanta, in scopul declarat de testare locala de aplicatii Delphi pe baze de date SQL inaintea scalarii acestora pe servere reale Interbase, Oracle, Sybase sau Informix.
M-am intrebat desigur cam ce monstruozitate va trebui distribuita clientului si pe cate CD-uri? Ei bine, o aplicatie tipica de baze de date cuprinde un executabil selfconsistent de 500-700 KBytes si motorul de baze de date BDE, care ocupa 3 MBytes cu totul din care vreo 800 KBytes utili. In rulare, o aplicatie complexa MDI cu sase-opt forme de date deschise simultan nu consuma mai mult de un megabyte din memoria disponibila, incluzand si cache-ul BDE, si galopeaza pe un 386SX cu 4 MBytes de RAM. Cu asemenea cerinte Intel si-ar pierde repede painea. Noroc cu Microsoft
Iata un domeniu care imi displace profund. In enciclopedia galactica, la capitolul specii disparute, despre omenire se va mentiona ca a sucombat sufocata in hartii. Iar solutia gasita de Borland, purtand nefericitul nume de ReportSmith (forjorul de rapoarte!) este in perfect acord cu cele de mai sus.
Daca doriti sa scapati repede de sarcina ingrata a listarii de rapoarte, RS este o solutie dar - sa speram - una pe termen scurt. Editorul de query este pe cat de facil pe atat de simplist, incat de cele mai multe ori preferi sa elaborezi direct interogarea SQL. Adaugarea de campuri calculate devine un chin infiorator care presupune scrierea de macro-uri criptice in Basic, ca de altfel orice automatizare doresti s-o adaugi. Si nu in cele din urma, desenarea vizuala a raportului este o sarcina penibila cu instrumente si functii primitive. Iar portarea fontului draft de imprimanta intre diverse driver-e de imprimante se face dupa filozofia Microsoft: fonturile True-Type inainte de toate!
Adaugarea sistemului de rapoarte la aplicatia de baze de date se realizeaza cu RS Runtime, care poate fi pilotat prin DDE din programul Delphi. Dintr-o data, necesarul de cateva sute de KBytes de RAM al aplicatiei creste la cativa MBytes in momentul listarii raportului. Iar distributia se mareste si ea cu opt Mbytes.
Insa o solutie foarte buna(una peste care am dat si eu) este Report Manager. Acest utilitar foarte bun pentru crearea rapoartelor este facut in Delphi si ofera o conectivitate impecabila la baza de date, cat si crearea unui design al rapoartelor este excelent.
O imagine cu acesta putem vedea mai jos :
Dupa un an si jumatate de dezvoltare si inca pe atat de beta-testare Borland a livrat un produs remarcabil, destinat realizarii de aplicatii vitale pentru un sistem de operare recunoscut pentru limitarile si instabilitatea sa. Dincolo de paleta bogata de facilitati pe care o poseda, Delphi asigura aplicatiilor produse o exceptionala stabilitate si siguranta in rulare, mediul insusi bucurandu-se de o fiabilitate remarcabila: in citeva sute de ore de dezvoltare si depanare nu a crapat niciodata!
Cum nimeni si nimic nu este perfect, realizatorii lui Delphi mai au numeroase deziderate de satisfacut si numai viitorul va confirma capacitatea lor de a-si sustine si perfectiona produsul.
Compilatorul genereaza in continuare numai cod pe 16 biti. Optiunea de compilare de ocolire a erorii din coprocesorul Pentium-ului nu are nimic de-a face cu optimizari de cod pentru Pentium. Instructiunile pe 16 biti antreneaza o reducere la jumatate a performantei potentiale in prelucrarea intregilor pe 32 biti precum si in operatiunile intensive cu memoria, iar noile tipuri de obiecte se aloca toate in memoria dinamica!
Subsetul limbajului SQL pentru interogarea tabelelor in format Paradox si DBase este handicapat de limitari drastice, care sunt de dorit sa dispara, ca si lipsa suportului pentru operatiuni tranzactionale pe aceleași tabele.
Delphi a fost conceput din start ca un mediu neechilibrat: face totul pentru dezvoltatorii de aplicatii si nimic pentru programatorii de obiecte. Nici documentatia nu ii sustine pe aceștia din urma, pentru atingerea de scopuri profesionale fiind obligatorie achizitionarea de referinte de limbaj si documentatii suplimentare ca si de sursele bibliotecii de componente. Insasi modul categoric de departajare al utilizatorilor de Delphi in dezvoltatori si programatori ar putea inregistra un esec rasunator daca Windows-ul lui Microsoft nu se axeaza pe aceasi directie extinzand dihotomia la intregul sistem de operare. In ceea ce priveste suportul OLE, Borland a gresit in trecut nealiniindu-se la Microsoft: va gresi acum tinandu-se prea aproape?
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1884
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
