kako je najbolje unutar grupe ljudi, (firme jel) …ugraditi slojeve poput:
rad s bazom
poslovna logika
user interface
Ideja je da ne dođe do svakoga sva prava za prčkanje po bazi…jer se onda ne zna tko pije a tko plaća. Ne postoji centralna točka za odgovornost itd…
A i narušen je DRY koncept, ako svatko za sebe vadi iste stvari iz baze, što će reći da se poslovna logika izvršava na više mjesta…što očito ne valja.
Moj neki grubi koncept je sljedeći, a ako netko ima volje i iskustva…neka me nadopuni.
Database layer - zamišljam kao sloj gdje ljudi rade isključivo na arhitekturi baze. Tu se pazi da baza podržava zahtjeve koji se od nje očekuju, što strukturom, što optimizacijom.
Eventualno se na ovom sloju možda mogu graditi i procedure koje vraćaju određene setove podataka? No nebi ovaj layer nikako opterećivao poslovnom logikom, jer procedure nisu dovoljno fleksibilne da to uobliče?
Web servis - ovaj sloj pak zamišljam kao izvršni član i jedino mjesto na kojem će se odvijati poslovna logika.
Web servis znači i dalje ima puni pristup prema bazi, ali je ideja unutar njega izgraditi metode koje ne mogu narušiti bazu…i koje će biti ponuđene za rad onima koji se koriste tim servisom.
Znači unutar web servisa se odvija kontrola svih permissiona, i samo ono što zadovoljava se dalje prosljeđuje prema bazi. Na taj način je web servis poput sigurnosnog zida između baze i onih koji grade bilo kakav user interface na osnovu podataka iz baze. Naravno, i sve akcije iz toga user interfacea su ograničene onim što dozvoljava taj sigurnosni zid da se desi.
Svatko tko pristupa web servisu također dobiva i određeni pristupni key koji ga ograničava koje metode servisa može koristiti.
User interface - to je onda sirova implementacija user interface-a. S time, da u ovom slučaju za integraciju user interfacea i dalje imamo backend i frontend dio. Ovisno o tehnologiji. Ne znam za mobilne aplikacije i android kako to točno ide…ali znam da za web i dalje treba postojati backend i frontend da bi se web izradio.
Postignuto je znači da i razvojni odjel mobilnih aplikacija i razvojni odjel web aplikacija koristi isti web servis za rad sa podacima…a onda je dalje na njima kako će ih prikazati korisniku, prema specifikaciji.
To je onako kako meni to pada na pamet. Za bilo kakvu nadopunu, bit ću zahvalan.
A i imam još pitanja u svezi ovoga…ali korak po korak, da ne udarim odmah sa svime
Ne, uopce ne. On prica o organizaciji ljudi prema Layeru aplikacije, a da li jet to jedan monolitni sustav ili microservice based aplikacije nema veze u ovom slucaju.
Prije svega me zanima koliko ljudi ima odjel i koliko je aplikacija velika i sto radite tocno. O tome uvelike ovisi i odgovor. Pokusavas odjel prilagoditi aplikaciji sto je pogresan smjer, da mogu nesto vise napisati trebaju mi ugrubo podaci koliko je velika firma, tvoj odjel i sta radite, jel to E-Commerce, jel imate in house aplikaciju koja je samo za in house upotrebu itd. Ne moras ici u detalje, ali cisto onako ugurbo jer ovo je vec pogresno, a kad ti odgovorim opsirnije uvidjet ces i zasto.
Aplikacija ima više i isti podaci se koriste kroz različite aplikacije koje imaju neki zajednički presjek. To bi možda sve bila i jedna kompleksnija aplikacija, da se usmjerio tako razvoj. Prepoznala zajednička kategorija svemu tome…ali sada je svakak.
Trenutno je to raštrkano i na destkop (“destkop” u ovom slučaju mislim na nstalacijski desktop program) i android i web. Koliko ja primjećujem, nerijetko je da neki android-aš implementira iste stvari kao što se implementiraju i za web.
Nekako mi logika kaže, to što je zajedničko se mora izvući van i biti na jednom mjestu od kuda će se dohvatati i za android aplikacije i za web aplikacije. Web servis jel, koji bi sa svima komunicirao.
Aplikacije su uglavnom orijentirane da olakšaju poslovanje drugim firmama…dalje od toga ne znam što bi rekao o njima da je bitno za temu.
Problem koji vidim je da se stvari jako loše recikliraju i tako one stvari koje su doslovice jedna stvar i koja se nikada više nebi trebala ponavljati, ispadne da se zbog neorganizacije mora svako malo ponavljati…
Kada bi ti dočarao do kuda sve seže ta njihova neorganiziranost, pao bi ti mrak pred oči.
Oni nisu čak primjetili niti da je novi klijent novi UserID, pa kada se aplikacija proda novom klijentu…pravi se copy-paste cijela nova baza za tog klijenta. Pa održavaj xx baza koje imaju istu strukturu…kad dođe potreba za nekom promjenom.
Pa kada dođe ta potreba za promjenom…onda je ajme majko na kojim sada bazama to treba ažurirati a na kojima ne?
A i zahtjevno je to ažurirati desetke baza podataka, radi samo neke sitne promjenice…pa se ažuriraju samo neke. Pa puca vamo…puca tamo…kad pofali neko polje ili procedura. Veselo.
Moj odjel sam za sada samo ja i ljude koje ću tek dovesti.
Do sada sam uspio samostalno ispratiti sve zahtjeve koji su pali pred mene…i otvorene su mi ruke da razvijam web odjel. Da zaposlim…da strukturiram…
Pa imam potrebu da u temelju postavim što ispravniju strukturu. Mislim, vjerujem da i ovako znam puno bolje to složiti nego što je…jer koliko vidim, niti nemaju taj sloj koji bi trebali imati. Ali mislim da mi svakako nebi škodila i nekakva kvalitetna obuka/knjiga na ovom polju…ako ne to, barem da dobijem pokoji korisni forumaški savjet…pa da mogu vidjeti dalje nego što trenutno vidim.
Jer recimo jako teško apstraktiram kakvu organizaciju moraju imati tipa Facebook ili Google, da poslože sva ta prava pristupa koja postoje unutar zaposlenika. Ali to je sigurno jedan sasvim drugi svijet ako pričamo o takvim mega-strukturama. Ja bi sada malo megalomanski htio sve tip top…a hrpa požara koje treba pogasiti, xd.
Ovo se u mom frameworku zvalo “kp”. -> kontrola pristupa
Ako sam dobro shvatio, “Datalayer” radi sirovi dohvat, spremanje ili edit podataka? Znači “mutavi” query koji nema pojma tko koga i zašto, on će obrisati neko polje ako mu je rečeno da ga obriše.
A biznis logika je ona koja daje zadatke tim queryima i koja razmišlja:
“Aham, pristupa taj i taj user…ajmo provjeriti da li on smije raditi traženu akciju.”
Zatim tu provjeru napravi pozivajući “mutavi” query …i ako je provjera pozitivna onda shodno tome poziva sljedeći “mutavi” query koji će odraditi traženu akciju.
Tako ja nekako to vidim, a čini mi se da i ti na isto misliš.
Prema tome mi se čini da ispada van cijela odgovornost onoga koji vodi Datalayer. On naravno ne smije napisati krivi query koji će pobrisati nešto što nije očekivano…no tu je i teže pogriješiti.
A većina odgovornosti leži na onomu tko kreira biznis logiku i koji kreira uvjete. Ajmo reći taj level vidim kao sigurnosna vrata kroz koja ne smije proći ništa “neželjeno”.
Sve one prije tih sigurnosnih vrata (servisa), smatram da ne smiju imati moć napaviti sranje bazi, čak i kada bi željeli napraviti sranje bazi.
Doslovice kao kada ti facebook da pristup njihovom API-u. Niti jedan developer nebi smio moći pomoću tog API-a naštetiti Facebooku…
Tako mi se čini i ovdje, da svi developeri koji pristupaju bazi kroz taj servis (sigurnosna vrata)…da nebi smjeli moći nauditi bazi, sve i da žele.
Lakše reći nego učiniti, jer ako bi baš picajlizirao kontrolu…postavlja se pitanje:
recimo developer kroz taj servis ima opciju obrisati neki komentar. Tu akciju brisanja komentara originalno trigira korisnik aplikacije, a biznis logika određuje da komentare ima pravo birsati administrator ili autor komentara. Kako taj servis može znati da je trigirano brisanje ispravnog komentara, tj. da developer nije putem nešto krivo povezao… Može se snimati što je tko radio, pa tako i povratiti podatke u slučaju greške…ali kontrolirano ograničiti grešku ne vidim mogućim?
To je moguće picajliziranje, jer tu se greška opet teže podvuče…a lakše testiranjem uvidi.
Ako imas potrebu za dohvat podataka sa vise razlicitih app, u tom slucaju radis web servise.
Onda kod desktop app umjesto datalayera imas sloj koji zove web servis sa odredjenim parametrima, a u business logici zoves odredjene funkcije iz sloja koji komunicira sa web servisom
U business logiku ti ide sve sto ti treba.
Kod mvc-a, slozis si library(curl) koji zove web servis kojem predajes parametre, url i sl. ,a autentification podatke citas iz configa.
I taj library zoves iz controllera, tako da tu onda nemas model.
Osim ako zapisujes logove u bazu, ali i to rjesis preko web servisa.
Ako hoces da je web servis brz, koristi go lang i stavi web servis na linux.
