Citat:
|
Pa da li bi neko ko zagovara "fat model ..." mogao da mi posjani zasto treba da sledim takvu organizaciju.
|
Kratak odgovor: Zbog fleksibilnijeg dizajna koji dobijaš enkapsulacijom poslovne logike i razdvanjanjem odgovornosti između komponenti sistema.
Dugačak odgovor:
Prvo primer: Razvijaš aplikaciju za manipulaciju izborima
. Potrebno je da vodiš računa o trenutnom stanju na glasačkim mestima i da generišeš izveštaje operateru koji koristi aplikaciju. Ukoliko stranka gubi izbore operater može preko tvoje aplikacije da prebaci novac sa offshore stranačkih računa na račune korumpiranih posmatrača, glasača, brojača i sudija. Takođe mora da vodi računa o tome koja korumpirana osoba je odgovorna za koje biračko mesto.
Osnovni entiteti su ti BirackoMesto, Operater, Stranka, Racun, Posmatrač, Glasač, Brojač, Sudija, itd.
Imamo osnovne slučajeve korišćenja: Ažuriranje stanja sa biračkog mesta, Pregled odnosa između stranaka, Transfer novca sa računa na račun, Generisanje izveštaja o troškovima, itd.
Sve je ovo osnovna logika sistema (poslovna logika) koju ti nekako moraš da modeluješ svojom aplikacijom. Pokušaj da posmatraš razvijanje ove aplikacije van okvira tvog frejmvorka i van okvira web aplikacija uopšte. Posmatraj samo logiku sistema jer je to jezgro onoga što moraš da implementiraš.
BirackoMesto mora da poseduje operacije za vraćanje informacija o trenutnim glasovima, koji posmatrać je zadužen za to biracko mesto, da genriše izveštaj o ukupnom trošku za to biračko mesto itd.
Takođe i ostali entiteti bi trebalo da imaju operacije koje obavljaju funkciju koja je usko vezana za te entitete.
Na ovaj način možeš da razvijaš aplikaciju koristeći osnovne entitete i neke pomoćne kao što je na primer klasa TransferNovca koja enkapsulira logiku transakcije sa računa na račun. Objektu te klase proslediš račun sa kog prebacuješ, račun na koji prebacuješ i količinu novca a on sadrži svu logiku prebacivanja tog novca.
Ovakav dizajn ti omogućava veću fleksibilnost jer na primer možeš da iskoristiš postojeću logiku adaptiranjem postojeće klase. Na primer TransferNovca u klasu SiguranTransferNovca koja je zadužena za prebacivanje novca na način kojem se ne može ući u trag.
Ako primećuješ nigde nisam spomenuo kontrolera. Kontroler je za implementaciju aplikacione logike nepotreban.
Kontroler je koristan kod implementacije REST, a samim tim i HTTP aplikacija. Tvoja REST aplikacija mora da prihvati zahtev, na osnovu parametara zahteva izvrši određenu funkciju (logiku) sitema i da sve to lepo prezentuje.
Zato se odlučujemo za MVC pattern. Controler prima zahteve i na osnovu parametara instancira Model(e) i renderuje View koji je vezan za te Model(e).
Ovakav dizajn omogućava lakše testiranje aplikacije. Logiku sistema možeš da izvršiš nezavisno od interfejsa u koji je ona uključena. Odnosno, ne moraš da lažiraš HTTP zahteve, što omogućava lakšu automatizaciju testiranja.
Aplikaciju možeš brzo da adaptiraš za upotrebu u desktop, web, console, mobile aplikacijama.
Što se tiče ORM-a on je samo to što mu ime kaže mapiranje objekata u relacioni sistem. Predstavlja samo sloj između objektno orijentisanog koda i relacionih baza podataka jer su to dva veoma različita sistema.
Česta je zabluda da se dobro OOP svodi samo na primenu osnovnih pojmova objektno orijentisanog dizajniranja(OOD) (abstrakcije, enkapsulacije, polimorfisma i nasleđivanja). Pored ovih teorijskih pojmova postoje i osnovni principi koji predstavljaju vodilje prilikom osmišljavanja praktičnih rešenja (Googluj Object Oriented Principles).
Fat Controler krši nekoliko OOD principa. Ali mnogo sam već napisao tako da ću ovde da stanem.