Citat:
nikitaGradov:
I moja prva ideja je bila da kontrolu uradim kada on izabere ponudu i klikne na neki button. Ali, to mi se bas i nije pisalo, jer bi kod bio nesto ovako, otprilike:
koja je izabrana ponuda? (morao bih da je prepoznajem po njenom nazivu, tj. u nazivu ponude bi moralo pisati i koji je vremenski interval)
koje je tekuce vrijeme?
uporedi tekuce vrijeme sa vremenom koje mora da postoji u nazivu ponude?
itd ...
Pokušaću ovo detaljnije da objasnim na jednom primeru.
S obzirom da se radi o blagajničkoj aplikaciji, pretpostavićemo da pravite client-server aplikaciju.
Pošto ne znamo o kojoj se aplikaciji radi, za primer ćemo uzeti da je vaš klijent firma koja se bravi prodajom oglasnog prostora u lokalnim novinama.
"Postoji više tipova oglasa (prodaja/kupovina nekretnina, motornih vozila, itd.) Svaki oglas ima osnovnu cenu, ali u zavisnosti od doba dana, cena oglasa se može umanjiti."
Na sledećoj slici sam napravio neki dijagram. Svaka
Usluga ima listu
Stavki i vreme pružanja usluge.
Stavka sadrži
Ponudu na koju se odnosi, cenu i popust u tom trenutku (npr. danas oglas vredi 100 dinara, a pre 2 godine je bio 85) , opcioni opis (npr. umanjeno 10% zbog uplate u 13h).
Ono što je ovde bitno je da entitet
Ponuda ne treba da zna za aktuelne popuste, pa samim tim ni za početno i krajnje vreme jer to nije ono što definiše ponudu. Poseban sloj aplikacije će se pozabaviti ovom problematikom.
Kada korisnik iz combobox-a bira
Ponudu, dovoljno je da se prikaže samo
Nekretnine, Vozila. Mislim da je bespotrebno pisati
Nekretnine 11-13h, Vozila 11-13h, itd.
Na server strani napravite novi
service layer (neki ga zovu još i
application layer) pod nazivom
DiscountService koji će na osnovu prosleđenog PonudaId i trenutnog vremena na serveru odrediti da li za određenu ponudu važi neki popust ili ne. Sa ovim servisom dobijate sledeće pogodnosti:
1. Popust i Ponuda su potpuno razdvojeni. Npr.
"ako kupite oglas za nekretnine, dobićete 5% popusta za oglas za vozila". Entitet OglasNekretnine uopšte ne treba da zna za entitet OglasVozila.
2. Ukoliko je deo za obračun popusta odvojen od svih ostalih delova, njegova izmena neće uticati na ostale delove sistema. Recimo, ako se donese pravilo da su svi oglasi sredom jeftiniji za 30% bez obzira na doba dana, tada
timer nema naročitog smisla, a i cim je za korisnika da svaki put instalira novu verziju aplikacije jer administrator uveo novo pravilo obračuna popusta.
3. Ukoliko se odlučite i za pravljenje
web verzije programa, moći ćete da iskoristite postojeću logiku, a izmene će direktno uticati na obe verzije.
4. Ukoliko iz nekog razloga imate više različitih formi koje služe za unos Ponuda, logika za popuste je na jednom mestu, tj. nije zakucana i duplirana na više mesta.
itd.
Citat:
nikitaGradov:
uporedi tekuce vrijeme sa vremenom koje mora da postoji u nazivu ponude?
Kod obračuna popusta ili bilo kakvog upoređivanja nekih entiteta, nikada nemoj koristiti njihov naziv, već njihov id.
Prvo, može biti jako teško isparsirati naziv.
Drugo, zahtev klijenta može biti da se iz naziva izbaci vreme, a to bi značilo da moraš da izmeniš celu logiku (dani i dani kodiranja).
Za svako dohvatanje, izmenu i brisanje entiteta, koristi isključivo njihov id. Za id se nikada ne uzimaju govoruće šifre (ne bi trebalo) kao što su JMBG, jer su iskustva iz prakse pokazala da 2 različite osobe mogu imati JBMG.