DB Abstraction Layer, koji koristite ?

[Ilija Studen]

Znao sam da će Blues ovako odreagovati. Već smo jednom vodili ovakvu diskusiju gde sam ja popustio. Ali sada je moj kung-fu zreliji i bolji

Originalno napisao bluesman

Još kada čujem da nekome treba "abstraction layer" da se nebi petljao sa maysql i kreiranjem querija, onda stvarno ne shvatam kako neko može da se "bakće" sa web programiranjem, piše profesionalne web aplikacije, optimizuje ne samo php kod nego i mysql querije, a da ne želi da se bakće sa mysql.

Nadam se da će ovo ispasti dobar fazon (to je osnovna namera):

Još kad čujem da nekom treba automobil kako se ne bi petljao sa biciklom i pedalanjem onda stvarno ne mogu da shvatim kako neko može da dođe na ideju da krene iz tačke A u tačku B, prelazi taj put uz optimizaciju uloženog truda, a da se ne bakće direktno sa svojim prevoznim sredstvom.

Naravno, biciklo je sasvim dovoljan za većinu svakodnevnih zadataka, ali mi ipak volimo udobnost koju nam automobil pruža, štiti nas od vremenskih nepogoda i uopšteno ulažemo znatno manje sopstvene energije u rešavanje problema. Automobil više troši i skuplji je... Stvari koje smo spremni da oprostimo jer nam zauzvrat pruža dovoljno da opravda te stvari.

Ako treba na brzaka da odletim do obližnje prodavnice sešću na biciklo, ali ako treba da pređem nešto ozbiljniji put onda ću se definitivno odlučiti za auto. Po meni je ovo sasvim logičan način razmišljanja.

---

Tražeći optimalno rešenje za opis podataka sa kojima aplikacija barata našao sam sledeće gradivne objekte:

- sam objekat (korisnik, grupa, vest...) sa svojim svojstvima
- relacije (blog unos ima više komentara, komentar pripada jednom blog unosu)
- validatori (naslov unosa ne sme biti prazan, email adresa mora odgovarati navedenom formatu)

Ono što tebe ne treba da zanima je na koji način će se opisani objekti čuvati (bitno je da budu sačuvani) i kako će se razrešavati relacije među njima. Ono što treba da te zanima je da ti ti objekti budu dostupni i da budu trajni, te da objekat koji sadrži neisprvne podatke ne smeju biti sačuvani (uloga validatora). Klasična crna kutija: ne zanima te šta je unutra dokle god radi ono što si joj ti naložio da radi.

Ako si precizno definisao svojstva objekata, relacije među njima i pravila ti si odradio nekih 70-90% posla. Sve što treba da uradiš je da programiraš izuzetke od opšteg ponašanja i napraviš korisnički interfejs.

Propel ti recimo omogućava da navedena pravila definišeš pomoću jednostavnog XML fajla. Na osnovu njega dobijaš generisane klase, SQL za generisanje konstrukcije baze (u skladu sa platformom), a u fazi razvoja je i mehanizam da dobiješ i gotove forme. 100% free!

Rails ti sa druge strane pravi definiciju analizirajući tabele u bazi podataka dok specifičnosti koje ne može sam da zaključi (validatori, relacije...) definišeš ti unutar model klase pomoću par krajnje jednostavnih komandi. Zauzvrat ćeš čak dobiti potpuno funkcionalan model plus osnovne forme i listanja. Pogađate? 100% free!

---

Za jednostavne stvari se ne ispati dovoditi artiljeriju, ali ako je problem sa kojim se suočavaš iole ozbiljniji zna se. Uštede u vremenu su ogromne, a to znaju osobe koje su radile sa sličnim rešenjima.

Rails važi za ultra produktivno okruženje. Razlog: konvencije, kvalitetan ORM, testiranje, opšte stvari se razrešavaju automatski, programer definiše samo izuzetke. Mislite o tome...