Citat:
spartak: Aha, u teoriji.. To jest cak i u teoriji projektovanja ostavljaju rezervu da se deo biznis logike ponekad mora preslikati do UI. A praksa cesto pokaze da ta teorijska rezerva nije za dzabe rezervisana
Pogotovo u web aplikacijama, gde je "skupo" vracati korisnika svaki cas na server da bi prosao neki biznis flow, validaciju ili bilo sta drugo.
Ucaurivanje biznis logike u UI layer je definitivno losa praksa, narocito ako je jedinu tu i prisutna (znam, ti si rekao preslikati, samo naglasavam poentu).
Ako ne vidis cistu liniju izmedju UI i biznis logike, to znaci da nisi dobro odradio arhitekturu sistema. Na stranu osnovna validacija, konkretan business layer odradjuje svoj posao na osnovu vise faktora/resursa koji bi bili preskupi za odrzavanje i kesiranje u UI (ako treba da konsultujes tabelu od milion redova naravno da ces raditi post back umesto da tih milion redova ubacis u javascript), da ne pominjem da vecina ljudi pravi gresku i osetljive algoritme/podatke koji predstavljaju poslovnu tajnu firme trpaju u javascript module na web stranicama da bi dobili na performansama (cudo jedno koliko se moze nauciti o poslovanju jedne banke posmatrajuci html sors ebank aplikacije
) Da ne pominjem da user moze slobodno da ugasi javascript i sta onda?
Ili moze da ga debaguje i da preskoci neke vazne segmente i formira maliciozni zahtev sa same stranice ili nauci format POST paketa i posle ga replicira ili jos gore pusti svoj process kroz processflow na koji nema prava ili koji moze da napravi havariju.
Kad to sve stavis na papir onda vidis da je jedina stvar koju ti realno mozes da ubacis u UI ustvari osnovna validacija polja (polje prisutno? opseg ok? format ok?), uz PONOVNU validaciju na serveru. Sve ostalo zahteva taj skupi post-back, u cemu lezi sve veca popularnost AJAX-a tj. Atlasa, koji teze da minimizuje tu "cenu".
E sad kontrole, ubacivati business logiku u kontrole je, bar po meni, jos gore. Time zapravo zakljucavas funkcionalnost kontrole na odredjenu "primenu", pa se postavlja pitanje cemu uopste kontrola, bolje onda lepo stavi tu funkcionalnost na samu stranu/formu... Vise puta sam video to u praksi, projekat sa hiljadu user kontrola, a svaka se koristi samo na jednoj strani/formi zbog nedostatka genericnosti, a ceo problem uglavnom pocinje oko zablude da je code-behind iza aspx/ascx ustvari deo business layera, onda se ljudi zalete i nastaju problemi, posto ne mozes iskoristiti ascx deo bez ascx.cs dela
Drugi problem nastaje pri upgrade-u sistema, sta ako se promeni odredjeni aspekt business logike. Recimo firma promeni svoj account format i trba uskladiti validaciju. Promeniti to u dobro projektovanom business layeru je posao od 5 minuta. Pronaci i promeniti logiku u 200 procesnih user kontrola medju hiljadu je sizifovski posao. I to je nazalost simptomatika upotrebe kontrola, vecina korisnika ne razmislja o kontroli kao o necemu generickom i konfigurabilnom sto ce biti upotrebaljavano u razlicitim kontekstima, skoro svi ih koriste da grupisu kontrole na jedan panel
sto jedino ima konkretnog smisla ako je aplikacija "portalskog" tipa gde je vizuelni sadrzaj dinamicki odredjen.
l dobro, sad zastranih ovde, poenta je bila da je obavezno imati samo-dovoljan busines layer koji ni u kom smislu nece zavisiti od UI-a i koji ce biti dobro zasticen od UI-a. Osnovno BL test pitanje za bilo koji usecase je: "mogu li simulirati sva scenarija processa kroz kod bez user interfejsa?". Ako mozes onda si ok. Ako ti kroz kod mozes da posaljes "bombu" koja ce napraviti kurslus u business layer-u i onda zavisiti od user interfejsa da te zastiti od tog scenarija, onda definitivno nisi ok.