Citat:
Informer:
Ista stvar se primenjuje i na polje koje je definisano kao JMBG samo sto baza u ovom slucaju nema ugradjene mehanizme za to vec korisnik sam mora da napise. Ja uvek polazim od toga da je baza prva (ili poslednja - zavisi od kog ugla se gleda) linija odbrane i ne moze se zaobici.
Kada kazem "zaobici" mislim na neke druge procese/servise itd. Zato uvek i bez izuzetka napravim stored proceduru i sve te stvari se obavljaju preko procedure. Ukoliko dodje do promene logike samo udjem i promenim proceduru i ne moram da brinem da li je mozda jos negde ostao stari kod. Takodje, nekad je potrebno radi same validacije da se napravi nekoliko ozbiljnih upita u bazu da bi se dobio rezultat validacije. Uvek gledam da je bolje da to uradi sama baza nego neki back-end.
Ovaj tvoj pristup je jedan način gledanja na stvari, nije neispravan, ali se sve ređe primenjuje, iz razloga nepraktičnosti. Može da ima smisla ako se radi o nekoj izuzetno pipavoj optimizacijipa se hvata za svaku slamku da se brže dobije rezultat.
U praksi se pokazalo da je bolje bazu gledati kao skladište podataka (storage). Kao takva ona ne treba da zna ništa o svrsi podataka sa kojima radi već samo da skladišti podatke. Poneko čak na nivo baze ne implementira ni referencijalni integritet, madaja ne bihišao baš toliko daleko.
Kada se tako gleda, baza ne treba da o JMBG zna ništa više nego da je to niz znakova (ili broj, zavisi kako to ko definiše). Ne može da validira dali je JMBG ispravan, već samo da li je odgovarajućeg tipa i da li se uklapa u pravila referencijalnog inegriteta. I ništa više od toga.
Sledeći stvar je da bazi ne može neko tek tako da pristupa, već to mora da radi preko sloja za rad sa podacima (Data Layer). DataLayer je taj koji može da implemetira dodatna pravila, pa i da impementira validaciju JMBG. U tom kontekstu, potpuno je pogrešna postavka da dve apliakciej mogu da pristupaju bazi. To se nikako ne radi, dve apliakciej mogu da pristupaju istom sloju podataka (mada i to uslovno jer je i to najčešće previše nizak nivo pristupa).
Sloj podataka i dalje ne zna sve o podacima sa kojima radi. Može na primer da zna koji je tačan format JMBG i da radi tu vrstu valdiaciej ali ne zna čemu JMBG služi u širem kontekstu. TO radi poslovni sloj (Business Layer). Poslovni sloj zna čemu podaci služe,kakvi su njihovi odnosi i šta sa njiam može da se radi. On može da radi i validacije koje su znatno višeg nivoa (tipa, ovaj proizvod može da se poručuje samo ako ga ima na stanju).
Ako se vratimo na priču o dve apliakcije koje treba da pristupajusitim pdacima, naslućuje se da bi u stvari te apliakcije trebalo da pristupaju poslovnom sloju jer samo on obezbeđuje primenu i svih poslovnih pravila. Međutim tom sloju se ne pristupa direktno već preko aplikativnog interfejsa.
Namena apliaktivnog interfejsa je da napravi izolaciju izmedju serverske aplikacije i klijenata u svakom smislu: obezbedjuje se nezavisnost od platforme, univerzalnost podataka i slično). U praksi to su REST, SOAP i slični protokoli.
Ovo nije teorija, ovako se radi u praksi iz mnogo razloga. I čak se ne radi u ovako malo slojeva kako sam opisao nego to ume da budo mnogo finije razrađeno. Naravno, ovako postavljen sistem je složen i može da postane nepraktičan kada se radi neka jednostavna apliakcija. Tada se navedeni slojevi spajaju i pojednostavljuju. Za jednostavnu PHP apliakciju, čaki neki CMS, može sve da se svede na bazu i podatkovno-poslovni sloj i eventualno api sloj ako treba vise apliakcija da deli iste podatke.
U praksi, jednostava PHP apliakcija može da ima slojeve:
- baza, koja samo implementira referencijalni integriteti validacije tipova;
- podatkovno-poslovni sloj, koji čini skup klasa a koej mogu da predstavljaju svaku tabelu pojedinačno ili provarene skupove tabela (na primer možeš daimaš klasu za zaglavlje porudžine i klasu za stavke porudžbine amožeš da imaš jedna objekat prudžbina koji su sebi sadrži zaglavljei stavke). Ove klase su zadužene i za sve validacije na nivou poslovnih pravila. To znači da ako ti treba neki podatak izbaze NIKADA nećeš pristupati bazi nego ćeš insancirati odgovarajući objekat koji predstavlja podatak oji ti treba i preko tog objekta ćeščitati ili upisivati podatke u bazu. U praksi to znači da se svi SQL upiti nalaze u ovom sloju. Gornji slojevi ne vide ni S od SQL-a. Umesto toga oni pozivaju metode klasa i daju im samo parametre na osnovu kojih će biti izgrađeni SQL upiti. Čaki ako su opdatkovni i poslovni sloj razdvojeni, poslovni sloj ne koriti SQL, i on se za sve manipulaciej sa bazompodataka obraća podatkovnom sloju koji gradi SQL-ove po potrebi.
- korisnički intefejs, koji se bavi prikazivanjem podataka, prikupljanjem podataka za upis u bazu isličnim poslovima akoji se obraća poslovno-podatkovnom slovu za sve manipulaciej sa podacima (čitanje, validacije, upis, brisanje itd...)
- obično se napravii API sloj, koji omogućava da i neke druga apliakcije mogu da koriste podatke iz baze a taj API sloj se takođe za sve manipulacije sa podacima obraća poslovno-podatkovnom sloju.
Ovakva organizacija omogućava da kad god treba nešto da se implementira u aplikaciji, tačno se zna gde se to radi, a ako treba nešto da se menja u funkcionalnosti takođe se zna gde se to radi i takva promena je odmah primenjena u svim drugim delovima apliakcije. Ne može da se desi da moraš na dva mesta da implementiraš nekufunkcinansot (na priemr validaciju) pa da, ako je potrebno da se promeni način validacije, moraš na oba mesta to da menjaš. Svaka validacija treba da se radi samo na jendom mestu, u onom sloju na koji se ta validacija odnosi. I nikada, niko ne sme da zaobiđe neki sloj, jer ako to uradi narušava integritet aplikacije.
Kao što vidiš, striktna zabrana "zaobilaženja" se ne odnosi samo na bazu, kako ti praktikuješ, već se odnosi i na svaki drugi sloj apliakcije. Ako je neko sloj zadužen za neki posao, niko ne sme da ga zaobiđe i da taj posao uradi drugačije.