Salutare.

Citeam mai devreme forumul RONUA, si am gasit un thread foarte interesant, in care cineva explica un model de arhitectura de aplicatie. DAL (adica data acces layer), care este comandat de un BL (adica business layer), si UI. Toate regulile sunt scrise in BL, si DAL doar executa ce i se spune. Cand mai apar campuri noi, se modifica DAL, se modifica BL, daca este cazul, si se modifica UI pentru a acomoda noile campuri. Daca se modifica doar regulile de validare, se modifica in mod corespunzator BL-ul. O sa-mi permit sa citez:

Actiunile BL-ului sunt predefinite si atomice. I.e. actiunile atomice sunt add, update, delete, retrieve, validate si handle error. Buuun. Si-acu, prin configuratie definesc un model de behavior adica zic ca o tranzactie pentru update-ul de document x (i.e. sa zicem editare/modificare de factura ca stim toti ce e aia) inseamna o mapare de parametri si un set de operatii atomice cu repository-ul de exemplu: daca fac un update pornesc o tranzactie (ceea ce inseamna si deschiderea conexiunii, crearea documentului XML sau whatever), pot sa am o validare daca (mai) exista factura cu pricina (cu Db-ul par ezample), am un set de update-uri pe antet + randuri, etc., commit/rollback (close connection, trimite XMl-ul, whatever), return-retrieve.  Fiecare operatie in sine e handled la eroare dupa cum e configurata. BL-ul parseaza actiunile, mapeaza parametri si le executa tratand erorile asa cum sunt configurate. BL-ul e generic dar se comporta adaptat la ce are de facut pentru documentul x. DAL-ul habar n-are ce face, numai executa comenzile trimise de BL. Iar DB-ul poate sau nu sa fie complex, in functie de cata logica pun in configuratie si cat vrea muschiul meu. In pricipiu DB-ul nu e foarte "fat" in logica; daca e DB - mai degraba urmaresc sa am constrangerile atent puse, ca sa mai am un nivel de validare (daca la capat am DB sau ceva .XML).

Bun, sa vedem ce se intampla daca modific ceva:

1. vreau sa mai adaug ceva operatii cand factura e modificata (i.e. ceva logica care sa-mi creeze ceva miscare contabila) - o adaug pur si simplu la configuratie, cu validarile si error handling-ul specific.

2. se schimba DB-ul/repository-ul mai apar campuri care trebuie sa apara in UI si sa fie modificate si alea: modific config-ul BL-ului la mapare, retrieve si update. Modific forma de la UI stiind ca am cateva valori noi care vor veni in dictionar cu numele ... si la update trebuie trimise si alea pe pozitiile respective.(si am un truc si pentru chestia asta care imi da o oarecare elasticitate si-mi reduce efortul)

3. Logica gen "daca campul1 e null atunci cimpul 2 se compune din cimpul3+campul4 altfel e campul2" in afara de faptul ca apare extrem de rar (si de obicei denota o carenta de design) se pot rezolva prin factory - trecute in config. Izolate in afara BL-ului generic intr-un BL specific, apelabile din BL-ul generic, configurat. 

Ce e mai sus e un exemplu si nu o descriere exacta si completa.

Avantajele: Nu prea trebuie sa scriu cod suplimentar. Ce am scris este testat si rastestat - la urma urmelor toate operatiile trec prin acelasi cod generic, bug-uri noi nu prea au de unde sa apara. Pot face modificarile on-line daca nu afecteaza UI-ul. Am independenta BL-ului fata de repository. Avand in vedere ca am componentele UI-ului updatate automat la pornirea clientilor de pe server, inclusiv modificarea & deployment-ul componentelor UI-ului se poate face trivial si extrem de rapid. Standardizarea la nivelul structurilor care se schimba intre client si server (eu prefer sa las in pseudo-dictionare valorile) -> UI-ul se dezvolta dupa reguli clare si constante. Pot sa modific oricand si oricum (in stream binar, criptat, blabla) fara nici un fel de dificultate comuniactia dintre client si server schimband 2 clase. Mai mult, pot sa modific daca vreau NATURA comunicatiei DUPA ce am dezvoltat toata aplicatia, extrem de usor si rapid. Am de facut o noua aplicatie? Ok: fac design-ul de DB, scriu configuratia si codez UI-ul. Am de creat automate? Ok: tre' sa creez numai o chestie de "interfatare" intre pasi BL. etc.

Dezavantaje: Timpul introdus pentru traducerea operatiilor "logice" in operatii "fizice" (e extrem de mic, jur pe cravata mea de pionier, nu se simte). Slabiciune pe partea de BL la operatii gen punctul 3 (care, oricum, mi se pare ca trebuie evitate). Lipsa (deocamdata) a unui "Business Facade" mai serios care sa-mi permita si configurarea dinamica, prin mapari si alte chestii, a UI-ului si comportamentelor lui - dar asta nici nu cred ca o s-o fac vreodata - care ar fi putut include si tipul 3 de logica. Si in cele din urma (dar nu cea de pe urma) absenta - in modelul pseudo-dictionar - a strong type-urilor.

Io zic ca e un model excelent. :) Si inca odata: nu l-am inventat eu - desi tare mi-ar fi placut. Tiii, la ce a ajuns thread-ul asta, creca arhitectura de aplicatii ar merita un thread separat :))

Replica urmatoare:

Super modelul
si ma intreb daca in afara ta il mai stapineste cineva - sau cit timp ii ia unui om nou sa il stapineasca

---------------------

Pai.... sa-mi fie cu iertare, dar asta e o problema tipica de VFP, care stie numai date. Si modelul asta, care acum este prezentat ca fiind excelent, e aplicat in VFP de ani buni!

Remarcati, va rog, limbajul EXTREM de tehnic si plin de buzz-words, de practic nu intelegi nimic. As fi putut zice acelasi lucru in jumatate din numarul de cuvinte, folosind numai termeni non-tehnici, ca sa priceapa tot romanul....

Doh. Spre asta ne indreptam?