Poti gasi o implementare in Codebook Framework 6.2

Se poate descarca de la http://sourceforge.net/projects/codebook/%22%3ECodebook%3C/a%3E

Bussiness Objects sunt in  common\Libs\cBizness.VCX

Din pacate, arhiva nu contine documentatie.
Codul insa este foarte comentat, sunt date explicatii practic la fiecare secventa de cod.
Mai mult se gaseste pe forumuri, cautand "vfp codebook", insa nu am gasit prea multe referinte la Bizobject, ceea ce te intereseaza in special.

Eu mi-am facut o clasa proprie, care combina o parte din functiile din dataobject cu cele din bizobject, lasand ca deschiderea cursoarelor sa se faca in alt obiect - pentru moment, in dataenvironment.
Ceea ce am facut eu este un obiect care se ocupa atat de Bussiness Rules, cat si de salvarea datelor editate. Aveam deja aceste functii continute in interfata utilizator, le-am separat acum intr-un obiect distinct.
Obiectul este un container, in care se pot aduce alte obiecte de acelasi fel, respectiv cursoare relatate parent-child, iar aste se poata realiza pe mai multe nivele.
Am inlocuit o serie de apeluri de metode cu RAISEEVENT() si BINDEVENT() si am obtinut un obiect mai generic.
Obiectul gestioneaza si parametrii comenzii SQL din care rezulta cursorul, respectiv requery, update, revert, precum si tranzactiile.
Oricum, sunt in faza de testare si este foarte posibil sa sufere modificari majore.
Ce nu am implementat inca, este stocarea regulilor intr-o baza de date, de unde sa fie incarcate de obiect odata cu cursorul, mod in care sper sa obtin cea mai mare flexibilitate.
Depinde si ce fel de aplicatii vei dezvolta. Daca dezvolti aplicatii web based, un bizobject absolut independent, realizat ca un COM server, poate fi foarte util. Insa intr-o aplicatie cu client VFP, dezavantajele datorate posibilitatilor limitate de a pasa/prelua un cursor la/de la un obiect COM pot fi eliminate prin instantierea in aplicatie, ca obiect VFP.
Nu as vrea sa se redeschida polemica privind aplicatiile online si cele distribuite, vreau doar sa precizez ca lucrez atat cu aplicatii online cat si cu aplicatii distribuite, care lucreaza offline si se sincronizeaza cu serverul atunci cand este nevoie si - mai ales - cand si cum se poate, chiar si pe suport extern, daca nu poate fi realizata o conexiune online.
In aceste conditii, clasa realizata de mine este un hibrid, adaptat aplicatiilor mele, si este mai putin "ortodox" decat o implementare de bizobject intr-un framework, destinat sa raspunda oricarui fel de aplicatii. Sigur ca si tu vei ajunge sa evaluezi aceste aspecte, si vei lua o decizie in concordanta cu cerintele tale. Este mai bine sa pornesti fara idei preconcepute - desi inceputul l-am facut deja :).

Spor la lucru!

Dan

Am sa incerc sa-ti dau cateva idei de pornire.
Iau un exemplu cu doua fisiere in relatie one-to-many, iar pentru exemplificare, sa zicem ca lucram cu facturi. Vom avea un fisier care contine datele din header-ul si subsolul facturii (pe care il voi numi header), si un fisier care contine pozitiile din factura (pe care il voi numi specificatie).
Cele doua fisiere se leaga prin campul IDFACTURA, definit ca si primary key in header si foreign key in specificatie.

Din punct de vedere al integritatii bazei de date, definim conditiile pentru inserare, stergere, modificare:
Nu vom permite inserarea unei inregistrari in specificatie daca nu exista inregistrarea corespunzatoare in header, vom propaga modificarea cheii primare din header (daca are vreun motiv sa se modifice :) ) in specificatie, si vom sterge inregistrarile din specificatie atunci cand stergem inregistrarea din header.
Acestea sunt "database rules".

Acum discutam din punctul de vedere al continutului inregistrarilor.
Luam inregistrarea din header. Utilizatorul a creat o inregistrare noua sau a modificat una existenta si cere salvarea ei. Mai intai o analizam prin prisma regulilor firmei (ca sa zic asa, daca vorbim de bizrules):
Daca nu are IDCLIENT, nu  are NUMAR FACTURA si nu are VALOARE, inregistrarea nu este valida (bussiness rule) si nu se permite salvarea ei. Acum se mai pot analiza si alte campuri, si, in functie de cum sunt completate, se poate considera ca userul a dat un "new", apoi a dat "save" in loc de "cancel", deci avem o inregistrare goala, pe care o abandonam fara sa-l mai intrebam daca vrea sa o completeze sau nu (daca nu a fost asa, data viitoare va casca mai bine ochii la ce apasa). Daca inregistrarea e mai completa, dar nu de tot, se poate considera ca a omis unele campuri, si se intoarce spre completare, cu mesajul corespunzator catre user.
La fel in specificatie - daca nu are ARTICOL, CANTITATE, PRET UNITAR, inregistrarea nu este valida, si procedam ca mai sus.
Daca exista header si nu exista nici o inregistrare in specificatie, headerul nu are motiv sa mai existe. Asa ca, daca este gol, se abandoneaza total operatia, daca nu, se semnaleaza utilizatorului sa completeze datele sau sa abandoneze el.
Cam asa vad eu lucrurile cu bussiness rules. Ele pot fi mult extinse, in functie de necesitati. Un exemplu, ramanand la factura - firma poate avea preturi diferentiate in functie de client; sau nu admite facturi sub o anumita valoare; sau nu admite plata ulterioara daca clientul este nou; sau ...
Aceste reguli pot fi codificate in bizobject, sau pot fi stocate intr-o baza de date, luate de acolo de catre bizobject si interpretate. Asta depinde de ce te hotarasti sa faci la implementare. Personal, consider ca varianta cu stocarea in tabela si evaluare in bizobject este cea mai flexibila. In tabela poti scrie chiar expresiile, intr-un camp memo, si le poti evalua in bizobject sau le poti executa cu execscript()
Daca le pui in proceduri stocate, este mult mai complicat sa te intorci la utilizator pentru completarea / modificarea inregistrarii in cazul in care regulile nu sunt respectate.
Procedurile stocate sunt practic singura solutie daca dezvolti o aplicatie web cu un client "subtire", care nu poate decat sa colecteze datele si sa le trimita serverului. Pentru aplicatii cu "fat client", cum este VFP, nu mai sunt absolut necesare. Precizez, e preferabil ca toate "constantele" variabile in timp sa fie tinute in baza de date si nu in cod, dar nu este obligatoriu sa se si execute acolo, fie ea baza de date MSDE sau server SQL, fie DBC (poti avea proceduri stocate si in DBC)

Daca nu ai in vedere dezvoltarea de aplicatii pentru e-commerce, menite sa lucreze intr-un browser, chiar si pe WAP, nu cred ca vei avea novoie de bizobject realizat ca si COM server, ci ca un FOXOBJECT.

Eu ti-as recomanda, pentru a avea un punct de pornire, sa iei obiectul din codebook si sa faci ceva experimente cu el. Iti creezi o baza de date de test, cu 2-3 fisiere, o interfata, si experimentezi. Nu pot sa-ti dau un exemplu concret, eu am un framework propriu, obiectele sunt create pentru a lucra in el, asa ca nici o secventa de cod, nici clasa respectiva nu te-ar ajuta mai mult decat ceea ce ai in codebook.
Sau poti sa faci un obiect care sa primeasca drept argument aliasul cursorului, il selecteaza, face verificarile si returneaza Truse sau False (caz in care, intro proprietate, sa zicem obizobj.message, pui mesajul catre utilizator). Interoghezi acest obiect inainte de salvare si, in functie de ce returneaza, salvezi sau dai mesajul si te reintorci in editare.

Dan

M-am uitat prin directoarele mele cu "goodies" si cred ca fisierele din zip-ul atasat acestui mesaj sunt cea mai buna documentatie. Nu este foarte specifica - trateaza problema la modul general, dar tocmai asta e ideea; bizobj-u' tre'sa fie foarte foarte reutilizabil (a se citi foarte generalizat). Daca ai scris in bizobj "Use Clienti" esti gata. S-a terminat cu reutilizarea.

Enjoy the doc.

Ok DAN !
Imi dau seama ca la tine e totul bine legat in framework si e cam greu sa extragi ceva mai simplu pentru exemplificare ...

Hai ca ai pornit de prea jos totusi cu exemplificarea :-)

Ideia e ca am citit cite ceva pe net (de cind am lansat discutia) de bizobject ca obiect separat de obiectul bizrule. Problema e ca citind fugitiv, am uitat sa marchez locul unde era treba asta explicata ..atunci eram preocupat de alte probleme.

Ce vreau eu sa evit : din "intimplare" (mi s-a parut in prima faza extrem de simplu !) am lucrat cu php + javascript intr-o aplicatie web , cu baza de date Interbase 6.0 (am trecut pe MSDE de circa un an si ceva...)
Era un cosmar sa fac unele modificari...uneori era nevoie sa modific scripturi php, alteori javascripturi, proceduri stocate in Interbase...
Acum, cu MSDE , am de modificat prin fox si prin procedurile TSQL stocate in serverul de baze de date. Mi se pare tot greoi !
As vrea sa pastrez MSDE-ul doar pentru stocare date ... sa incerc sa scot afara din serverul de baze de date toate regulile bagate prin definitiile de tabele.
Pe aici am de lucrat...cred :-)
De altfel m-am uitat prin bazele de date (care sunt pe MSDE) de la aplicatia de salarii si de mijloace fixe de la Ciel...Pai ale lor sunt parfum ! Simple, fara triggere, fara relatii complicate, fara constringeri meseriase...
Ale mele insa nu sunt chiar simple , uneori ...s-ar putea ca cei cu experienta in MSSQL sa ii apuce rasul daca  le-ar vedea :-)
Clasele din Codebook sunt totusi cam vechi si nu cred ca tin cont de imbunatatirile aduse de VFP9...
E doar o parere insa ...trebuie sa sap mai mult in ele ca sa le inteleg !

Acum , legat de bizobject , citind prin docul de pe DVD-ul lui Grig, eu am inteles ca acesta e responsabil cu extragerea datelor pentru interfata cu userul, actualizarea tabelelor din serverul de baze de date si furnizeaza metode de deplasare prin inregistrari, salvari, adaugari, stergeri, etc...
Obiectul bizrule ar veni adaugat la bizobject ! (aici am nelamuriri, ca nu am vazut un exemplu clar de cum se face !)
De fapt la unii autori am vazut ca se cam contopesc obiectele (cred ca si la tine in framework), altii prefera sa tina  separate.
Chestia asta de fapt m-a cam dat pe spate si m-a bagat in ceatza. De aici si intrebarea mea care a initiat discutia din subiectul mesajului !

Poate reusesc sa ii dau de cap si se clarific cite ceva.
Cine stie, poate ajuta cumva pe altii ...

Dane, merci de raspuns !

Tomita

Tomita,

Scuze daca am pornit "prea de jos". Dupa lipsa de reactie la acest thread - ma refer la cele 3 zile fara raspunas - nu prea am stiut de unde sa incep. De altfel, nici articolul din FoxTalk nu pare a porni de mult mai de sus.
Inteleg ca pe forum nu sunt exemple disponibile, altfel ar fi aparut ceva.
Si eu am sapat pe net si prin framework-uri, si ti-am spus la ce concluzii am ajuns eu. Am resimtit lipsa unui exemplu, singurul multumitor pe care l-am gasit a fost codebook, si el mi-a dat punctul de plecare. Chiar daca este mai vechi - la nivel VFP6 - principiile raman aceleasi, codul oricum se rescrie.
Poate totusi vei gasi exact ceea ce doresti.

Eu nu dadusem postului lui Grig sensul pe care i l-ai dat tu. Multumesc ca mi-ai atras atentia asupra acestui aspect.

Dan