Staleži u java svetu

Htedoh dati naslov Klasne podele u java svetu u smislu podele na slojeve kako smo učili iz istorije da je svako društvo bilo podeljeno, ali reč klasa ima posebno značenje u programiranju.

Čitajući jednu dobru knjigu po prvi put sam video kako se na moderan način vrši raslojavanje programa u nivoe i čime se programeri pomažu da bi to raslojavanje uradili na najbolji način. Svi smo učili da savremena softverska arhitektura podrazumeva najmanje 3 sloja:

1. korisnički interfejs
2. sloj poslovne logike
3. DB orijentisani sloj

U praksi se sve klase sistema dele u 4 kategorije:

• Klase domenskog sloja koje predstavljaju objekte i veze izmađu objekate u poslovnom domenu (npr. u bankarstvu bi to bili računi, korisnici...). Te klase ne treba da znaju ništa o klasama drugih slojeva. Tako da npr. klasa Kupac ne treba da zna ništa o tome kako će se ona predstaviti korisniku sistema (kao web, swing, konzolno i kako u okviru tih mogućnosti). Takođe ne treba da zna kako će se čuvati u bazi niti kako će se koristiti transakcije za kontrolu paralelnog izvršavanja. Svaka klasa iz ovog domena se preslikava u jednu ili više tabela u bazi.
  
• Aplikacioni sloj (naziva se i business transaction layer ili service layer) modeluje ponašanje sistema. Koristi sistemske transakcije da bi mogao omogućiti ispravan paralelni pristup. Klase ovog sloja treba da znaju samo za domenski sloj zato što manipulišu domenskim objektima (npr. klasa koja vrši novčane transfere mora imati pristup Račun objektu).
  
• Sloj perzistentnosti čuva objekte u nekim trajnim skladištima (bazi uglavnom, ali može to biti i fajl ili EJB) i na zahtev ih uzima iz skladišta. Takođe omogućava sistemske transakcije za pristup skladištu (commit, rollback, transaciton isolation). Treba da zna samo za domenski sloj jer npr. mora da sačuva i pronađe Kupac objekat, i za aplikacioni sloj. Dozvoljeno je da se ima veza sa aplikacionim slojem ali je boljne izbeći takve veze. Upravo nam pomoć aplikacionih frameworkova omogućava da izbegnemo te veze.
• Sloj korisničkog interfejsa treba da zna samo za domenski sloj jer treba da prikaže korisniku domenske objekte (prikaže Račun) i aplikacioni sloj jer taj sloj dobavlja i prihvata domenske objekte od interfejsa.
  

Primetite da se sloj poslovne logike podelio na aplikacioni i domenski.

Kako ovo funkcioniše pokazaću na primeru proste Wicket aplikacije koja omogućava izmenu podataka o korisniku. Sastoji se iz 3 stranice: prva prikaže formu za unos šifre korisnika, druga koja prikaže podatke korisnika čija je šifra uneta i treća koja prikaže da je izmena uspešno obavljena. Sva logika se nalazi iza 2. stranice jer ona mora da pronađe i prikaže korisnika za unetu šifru a da zatim snimi izmenu podataka o korisniku.

Ako bismo radili u čistom Wicket-u i JDBC-u dijagram klasa za ovaj primer bi izgledao ovako:

Ovde su korišćeni projektni obrasci: service pattern za Business transacition sloj i Data Access object (dobar opis DAO patterna: Core J2EE Pattern Catalog) za perzistenciju (klase: Customers i CustomersInDB).

Kao što se vidi krše se neka pravila razdvajanja sloja. Klasa DefaultEditCustomerService iz service sloja ima vezu sa DBTranasactionFactory i CustomersInDB iz peristence sloja. Osim toga i na drugim mestima postoji direktna veza sa implementacijom. Npr. EditCustomer bi trebalo samo da komunicira sa EditCustomerService interfejsom i da ne zna koja je implementacija u pitanju, međutim postoji direktna veza sa DefaultEditCustomerService implementacijom.

Ovaj problem se rešava preko Dependency injection-a recimo korišćenjem Spring frameworka. Dijagram klasa za to rešenje izgleda ovako:

Na dijagramu primećujete da su ostale samo veze ka interfejsima što znači da klase ne znaju sa kim komuniciraju, nestala je jaka spregnutost među njima upotrebom Springove podrške za dependency injection. Ali nestale su i klase koje se tiču transakcija jer smo upotrebili Springov transakcioni bean i na njega preusmerili metode iz aplikacionog sloja.

Kada se uporede ova dva dijagrama jasno se vidi koji je prostiji i lakši za razumevanje i održavanje.

Više o Dependenci Injectionu: članak Martina Fowlera i sažetiji članak na Wikipediji
Wikipedija o Springu: Spring Framework