BizObject - Profox - Forum

13.08.
2015 Profox > Forum
Home Articole FAQs Forum Imagini Downloads Guestbook Contact Search

Thursday, August 13, 2015 ..:: Forum ::.. Register Login
Forum Google Ads
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt
acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce
mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati
versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.
Search Forum Home
Visual FoxPro Clase VCX si PRG business object...

b u s in e s s o b je c t & b u s in e s s ru le
1 0 /2 7 /2 0 0 5 1 2 : 5 8 : 2 6 PM
business object & business rule
toni
(Romania)
40 posts
Buna ziua !
De ceva vreme tot sap pe net dupa subiectul de mai sus (business object &
business rule).
Teorie am gasit destula ...
Mar interesa , daca are cineva timp si a folosit asa ceva, sa incerce sa ma
lamureasca si pe mine, cum se defineste un business object, in ce moment , cum
pot adauga business rule la business object, chestii care nu reusesc sa le digerez
prea usor.
Vreau sa pun asa ceva in functie in aplicatiile mele, dar nu prea reusesc sa
injghebez nimic...
Un mic exemplu de cum se face ar fi edificator.
Sau poate stiti o carte in care are explicat mai detaliat asa ceva...
Tomita
1 0 /2 7 /2 0 0 5 1 : 1 8 : 3 1 PM
Re: business object & business rule
Grigore Dolghin
(Romania)
3954 posts
www.class
software.ro Heh.... asta da intrebare. Lasama sami revin, si o sa incerc sa pun diseara o lista
de locuri unde ai putea sa afli ce si cum.
Grigore Dolghin
Visual FoxPro MVP 2006 2010
Class Software
My blog
http://www.profox.ro/Forum/tabid/55/forumid/5/threadid/1733/threadpage/0/scope/posts/Default.aspx 1/11
13.08.2015 Profox > Forum
1 0 /3 0 /2 0 0 5 8 : 5 7 : 5 3 PM
Daniel Buduru
(N/A)
3168 posts
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
Daniel Buduru
1 0 /3 1 /2 0 0 5 2 : 3 2 : 0 8 PM
toni
(Romania)
40 posts
danbd wrote
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
Auzisem eu de asa ceva...nu stiam de link !
Multumesc Danbd !
E un loc de unde sa incep .
Sper sa aiba si ceva doc chestia asta...
Grig, daca mai ai timp (am o banuiala ca nu prea ai ! :) ) si chef, poate scrii si tu un
rind doua, ai zis ca te gandesti.
Multzam oricum de raspunsuri !
Tomita
1 0 /3 1 /2 0 0 5 4 : 2 1 : 4 8 PM
Daniel Buduru
(N/A)
3168 posts
toni wrote
Sper sa aiba si ceva doc chestia asta...
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 miam 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, leam separat acum intrun obiect distinct.
Obiectul este un container, in care se pot aduce alte obiecte de acelasi fel,
respectiv cursoare relatate parentchild, 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 intro 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
intro 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 intrun 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 lam facut deja :).
Spor la lucru!
Dan
Daniel Buduru
1 1 /1 /2 0 0 5 9 : 3 2 : 2 5 A M
toni
(Romania)
40 posts
danbd wrote
toni wrote
...
In aceste conditii, clasa realizata de mine este un hibrid, adaptat aplicatiilor mele,
si este mai putin "ortodox" decat o implementare de bizobject intrun 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 lam facut deja :).
Spor la lucru!
Dan
Dane, multumesc mult de idei !
E un concept destul de nou la mine desi am lucrat destul timp cu vfox 6 ...Ar fi
trebuit sa lucrez cu bizobject + bizrule de multisor... Dar timpul ma omoara...
Dane , pina nu vad un exemplu mic nu ma simt sigur pe mine :)
Am sapat prin DVDul lui Grig, sunt tone de informatii acolo...Incerc sa sintetizez ce
ma intereseaza...
Eram tare intrigat de cum se pune problema cu bizrule , cum le definesti , cum o
stabilesti pentru un anumit bizobject ...
Eu lucrez in prezent cu remote view cu baze de date facute in MSDE.
Am incercat sa bag majoritatea regulilor in proceduri si functii stocate, dar ... e un
cosmar apoi actualizarea la client, ca mai uiti una alta...
Tomita
1 1 /1 /2 0 0 5 1 1 : 0 4 : 3 6 A M
Daniel Buduru
(N/A)
3168 posts
Am sa incerc sati dau cateva idei de pornire.
Iau un exemplu cu doua fisiere in relatie onetomany, iar pentru exemplificare, sa
zicem ca lucram cu facturi. Vom avea un fisier care contine datele din headerul 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 sal 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 intro 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 ecommerce, menite sa
lucreze intrun browser, chiar si pe WAP, nu cred ca vei avea novoie de bizobject
realizat ca si COM server, ci ca un FOXOBJECT.
Eu tias 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 sati 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 tear 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
Daniel Buduru
1 1 /1 /2 0 0 5 1 1 : 1 8 : 2 4 A M
Grigore Dolghin
(Romania)
3954 posts
www.class
software.ro Hell yes, Dan :)
Unde naiba ai stat pana acuma? Si de ce nai fost abonat la grupul de la yahoo? :))
Eu as sintetiza conceptul de bizrules si bizobjects intro singura fraza: "Toti avem
validari prin programe, pentru a nul lasa pe user sa faca cel taie capul; ei bine,
alea sunt bizrules. Daca le strangem pe toate intro singura clasa (in care fiecare
regula e o metoda), punem clasa aia pe form, si in butonul de "save" apelam
metoda corespunzatoare formului, care intoarce .t. sau .f., functie de context, ala e
bizobj. Si cu asta basta. E aceeasi Marie, da' cu alta palarie."
Cum e? :)
Bottom line: ma bucur tare mult ca teai inscris pe forum, fiindca vad ca #1 ai
ceva de zis, si #2 imi mai iei mie din "sarcini". Thanks :)
Grigore Dolghin
Class Software
My blog
1 1 /1 /2 0 0 5 1 1 : 2 6 : 2 2 A M
Grigore Dolghin
(Romania)
3954 posts
www.class
software.ro Mam uitat prin directoarele mele cu "goodies" si cred ca fisierele din zipul atasat
acestui mesaj sunt cea mai buna documentatie. Nu este foarte specifica trateaza
problema la modul general, dar tocmai asta e ideea; bizobju' tre'sa fie foarte foarte
reutilizabil (a se citi foarte generalizat). Daca ai scris in bizobj "Use Clienti" esti
gata. Sa terminat cu reutilizarea.
Enjoy the doc.
Grigore Dolghin
Class Software
My blog
1 1 /1 /2 0 0 5 1 1 : 3 7 : 0 7 A M
Daniel Buduru
(N/A)
3168 posts
metoda corespunzatoare formului, care intoarce .t. sau .f., functie de context, ala e
bizobj. Si cu asta basta. E aceeasi Marie, da' cu alta palarie."
Cum e? :)
Grig, sinteza asta ar merita sa fie pusa in FAQ
De stat, am stat doar pe UT. Mam inscris aici pentru ca am recunoscut o "carte
de vizita" care imi spunea ca merita :), si vad ca nu mam inselat.
Dan
Daniel Buduru
1 1 /1 /2 0 0 5 8 : 2 9 : 2 7 PM
toni
(N/A)
40 posts
danbd wrote
Am sa incerc sati dau cateva idei de pornire.
Iau un exemplu cu doua fisiere in relatie onetomany, iar pentru exemplificare, sa
zicem ca lucram cu facturi. Vom avea un fisier care contine datele din headerul
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 sal 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 intro 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,
intrun 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 ecommerce, menite sa
lucreze intrun browser, chiar si pe WAP, nu cred ca vei avea novoie de
bizobject realizat ca si COM server, ci ca un FOXOBJECT.
Eu tias 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
23 fisiere, o interfata, si experimentezi. Nu pot sati 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 tear 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
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 sa parut in prima faza extrem de simplu !)
am lucrat cu php + javascript intro 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 MSDEul 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 mam 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 ...sar putea ca cei cu experienta in
MSSQL sa ii apuce rasul daca lear 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 DVDul 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 ma cam dat pe spate si ma 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
1 1 /1 /2 0 0 5 8 : 3 6 : 1 2 PM
toni
(N/A)
40 posts
Grigore Dolghin wrote
Hell yes, Dan :)
Unde naiba ai stat pana acuma? Si de ce nai fost abonat la grupul de la yahoo?
:))
metoda corespunzatoare formului, care intoarce .t. sau .f., functie de context, ala
e bizobj. Si cu asta basta. E aceeasi Marie, da' cu alta palarie."
Cum e? :)
Bottom line: ma bucur tare mult ca teai inscris pe forum, fiindca vad ca #1 ai
ceva de zis, si #2 imi mai iei mie din "sarcini". Thanks :)
Grig, pentru incepator ca mine in ale bizobjectului , "merge si asa !" :)
Tomita
1 1 /1 /2 0 0 5 1 0 : 2 0 : 5 8 PM
Daniel Buduru
(N/A)
3168 posts
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 frameworkuri, si tiam spus la ce concluzii am ajuns
eu. Am resimtit lipsa unui exemplu, singurul multumitor pe care lam gasit a fost
codebook, si el mia 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 lai dat tu. Multumesc ca miai
atras atentia asupra acestui aspect.
Dan
Daniel Buduru
1 1 /1 /2 0 0 5 1 1 : 0 8 : 0 2 PM
anonymous
(Romania)
0 posts
Indraznesc sa incerc o mica polemica ...
Eu nu as fi asa de grabit sami fac un obiect care sal arunc pe orice forma si care
sa se ocupe de validare. De ce ? Pai, de ce sa car o groaza de cod pentru
validarea tuturor combinatiilor posibile in fiecare forma ? Approachul pe care il
folosesc este dual: unul la nivelul bazei de date, pentru ca in anumite conditii,
validarea poate fi extrem de complexa si poate implica acces extensiv la mai multe
tabele, si atunci te trezesti ca plimbi o groaza de date intre server si clientul fat doar
de dragul de a nu folosi facilitatile unui server; al doilea ar fi mai curind un parser de
reguli, apropiat de ce spunea Danbd Adica imi stochez regulile intro tabela or
whatever, odata cu legaturile la formul respectiv, iar codul de validare isi incarca
doar cele necesare de acolo. Sigur, miar place sa am obiectul care doar il arunc
pe form si stie el mai departe sasi faca treaba, dar am impresia ca e un efort cam
mare. Acuma, cei drept, nu lam incercat, e doar o impresie personala.
Si as mai incerca doua intrebari visavis de niste afirmatii ale lui Dan, luindumi
libertatea sa deviez putin de la subiectul initial :
eu personal tind sa restrictionez tot timpul ON CASCADE DELETE, prefer ON
CASCADE RESTRICT. Vad ca tu recomanzi contrariul. Argumentul meu ar fi ca un
user neavizat, pe o structura suficient de "relationata", sa zicem de la 3NF in sus,
iti poate face surprize mari cu cascade delete. Si eu tind sa limitez sideeffecturile
pe cit posibil. Care ar fi argumentul in favoarea lor ?
de ce spui ca procedurile stocate sint singurul approach pentru o aplicatie bazata
pe thin client ?Te referi strict la VFP, sau la modul general ? NB, sint un fervent
adept al lor, am scris aplicatii compuse strict numai din proceduri stocate, dar as
vrea sa inteleg de ce zici ca e unicul, parerea mea e ca sint ceva mai multe
modalitati prin care poti aborda o aplicatie cu client thin.
1 1 /2 /2 0 0 5 7 : 5 3 : 4 6 A M
Daniel Buduru
3168 posts
(N/A)
....
Indraznesc sa incerc o mica polemica ...
Eu nu as fi asa de grabit sami fac un obiect care sal arunc pe orice
forma si care sa se ocupe de validare
.........
Nas intra in aceasta polemica :). Daca performantele sunt
cuantificabile, polemica nare obiect.. Daca nu sunt, e chestie de
preferinte ... de gustibus non disputandum est :).
Nu e vorba de un obiect aruncat in orice form, ci de un obiect
specific unei tabele sau unui grup, daca tabelele sunt intro astfel
de relatie. Si care face cam acelasi lucru cu Field Rule si Record
Rule, dar la nivelul bufferului (view), clientside, si nu la nivelul tabelei
din baza de date fie ea serverside sau local. Si, in plus, coreleaza
si inregistrarile parentchild, in aceeasi interfata. Cum zicea Grig, toti
avem aceste validari in programe.
Problema nu este unde faci validarea, ci cand faci validarea inainte
de trimiterea actualizarii catre baza de date, sau dupa. In functie de
ce alegi iar asta iar e chestie de preferinte :) sunt si posibilitatile
de realizare.
Si eu am preferat ca baza de date sasi poarte singura de grija,
indiferent prin ce aplicatie este accesata, fat client, thin client, sau
dintrun browse deschis in VFP developer. Am facut asta din VFP5,
si nu vad inca nici un motiv pentru a renunta la aceasta politica.
In inginerie exista o regula de baza, de la care nu se admit exceptii:
un element se defineste o singura data, intrun singur loc, indiferent
de cate ori este reprezentat in diferite vederi/sectiuni/proiectii etc.
Scopul este acela ca atunci cand se face o modificare, sa fii sigur ca
primul loc in care ai gasit definit elementul respectiv, este si ultimul
loc. Aplicand aceeasi regula unei baze de date, singurul loc in care
poti fi sigur ca definitiile nu sunt redundante este chiar containerul
bazei de date. Clasele si programele, prin natura lor, nu ofera
garantia unicitatii.
De aici sar putea trage concluzia incorecta ca sunt adeptul
procedurilor stocate si al thinclientului. Sunt adeptul oricarui sistem
care satisface aceste cerinte. Nu are importanta ce obiect face
validarea, o procedura stocata, un COM server, sau un fat client, atat
vreme cat lucreaza "cu materialul clientului", respectiv cu functiile
sau definitiile stocate in baza de date, iar baza de date face automat
validarea la salvare daca nu sa facut anterior printrun alt obiect.
In ceea ce priveste clientul, il aleg pe cel cu care se poate realiza
o interfata care ofera suport complet utilizatorului, respectiv acesta
nu trebuie sa fie nevoit sa tasteze a doua oara o informatie deja
introdusa in sistem, ci sa o poata aleage. Daca am preferat lucrul cu
Windows, cu "Visual XXX" ca mediu de programare, pentru usurinta
de a alege niste chestii pe care nu tii minte sa le tastezi fara
greseala, mai ales cand e cate o cale care depaseste lungimea
textboxul, dar, daca le vezi, stii care din ele iti trebuie, nu vad nici
un motiv sa pun utilizatorul in fata unui prompt dos sau a unui
bash. Folosesc orice sistem care poate oferi acest suport
utilizatorului, fie fat client, fie el thin client. Daca sunt respectate
aceste conditii, departajarea se face cu o functie de minim
pe resurse...
Desigur, se poate polemiza pe cat de necesare/ intemeiate sunt
aceste cerinte, dar, iarasi, este o chestie de preferinte, daca nu sunt
prevazute in vreun caiet de sarcini al unei aplicatii.
.............
eu personal tind sa restrictionez tot timpul ON CASCADE DELETE,
prefer ON CASCADE RESTRICT. Vad ca tu recomanzi contrariul.
.............
Nas zice ca recomand asta. Asa sa nimerit sa fie situatia fisierelor
luate ca exemplu. Regula mea este urmatoarea: daca am fisiere one
tomany obtinute prin atomizarea unei tabele, ON DELETE
CASCADE. Headerul si specificatia apartin aceluiasi document, nu
au sens una fara alta, deci le tratez in acelasi mod: stergerea
headerului se propaga in specificatie; stergerea tuturor pozitiilor din
specificatie duce la stergerea headerului (o factura care nu
factureaza nimic nu e factura asta insa este bussiness rule,
nu referential integrity) . Restrictionez insa stergerea unei inregistrari
dintro tabela "nomenclator" daca este referita oriunde in baza de
date.
..............
de ce spui ca procedurile stocate sint singurul approach pentru o
aplicatie bazata pe thin client ?Te referi strict la VFP, sau la modul
general ?
...............
Am spus ca sunt practic singura solutie. Ma refer la modul general. E
adevarat ca acolo, pe server, se mai poate face si altceva, a se
vedea insa postul lui Tomita: Era un cosmar sa fac unele
modificari...uneori era nevoie sa modific scripturi php, alteori
javascripturi, proceduri stocate in Interbase.
Eu consider ca divizarea codului care priveste actualizarea bazei de
date intre diferite aplicatii nu este fiabila, si prefer ca tot acest cod sa
se gaseasca in baza de date, indiferent cum este el apelat.
Interogarile pot fi oriunde.

Daniel Buduru
Pa g e 1 o f 1
Visual FoxPro Clase VCX si PRG business object...

Flat View Oldest To Newest
Search Forum Home
Copyright 20022013 Profox Terms Of Use Privacy Statement

BizObject - Profox - Forum

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BizObject - Profox - Forum

Загружено:

Авторское право:

Доступные форматы

13.08.

Home Articole FAQs Forum Imagini Downloads Guestbook Contact Search

Visual FoxPro Clase VCX si PRG business object...

Visual FoxPro Clase VCX si PRG business object...

Search Forum Home

Вам также может понравиться

BizObject - Profox - Forum

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BizObject - Profox - Forum

Загружено:

Авторское право:

Доступные форматы

13.08.

Home Articole FAQs Forum Imagini Downloads Guestbook Contact Search

Visual FoxPro Clase ­ VCX si PRG business object...

Visual FoxPro Clase ­ VCX si PRG business object...

Search Forum Home

Вам также может понравиться

Visual FoxPro Clase VCX si PRG business object...

Visual FoxPro Clase VCX si PRG business object...