Nisam hteo da otvaram novu temu. Ima li sta novo. Radim sa ovim i malo mi je nejsan odnos Root - Child :(

Ima mnogo toga za.
Jedino protiv je sto je kompleksno i treba dosta truda da
se shvati kako i sta sve radi.

Sta ti konkretno nije jasno kod odnosa root / child?

Mislio sam da niko nece da odgovori pa sam pitao generalno :)
To sto mi nije jasno oko root/child je vise pitanje dizajna. Video sam primer sa projektima u knjizi ali mi i dalje nije jasno kada pravim objektni model kako da razlucim sta je root i sta treba da bude child tom root-u, mozes li na nekom primeru da kazes sta bi recimo bilo child nnekog root-a i zasto?

Jos jedna stvar me buni ako recimo ima listu u bazi nekih "Vrsta", lupam vozila. I sada ta vrsta bi bila nova, polovna... ali i korisnik sada moze da dodaje neke svoje vrste (polupana, ostecena ...) e sad....
Ovu listu korisnik treba da vidi recimo u dropdownlist-u kada dodaje novo vozilo da bi odabrao njegovu vrstu. Sa druge strane korisnik ce imati neki grid koji ce mu prikazivati sve te vrste, a iz tog grida ce moci te vrste i da edituje/dodaje nove. Sada me buni. Da li ta klasa recimo "CarTypes" koja u sebi sadrzi recimo "CarTypeInfo" objekte, treba da bude BusinessList ili ReadOnlyList. Po mojoj logici trebalo bi da bude ova prva zbog edita/dodavanja. Ili mozda treba da postoji jedna iz jedne i druga klasa iz druge ali to je onda mnogo klasa :( Bas me zbunila ova stvarcica :)

Baš me zanima ima li još nekoga, ko je aktivan na ES a da je koristio/koristi CSLA.

Lupam glavu šta da uzmem kao primer, no kako su ovo bussines objekti faktura se nekako
nameće sama po sebi kao zgodan primer za tvoju root/child nedoumicu.

Elem, faktura ima svoje zaglavlje i stavke.

Kako to modelujemo u CSLA:



Faktura ima neke svoje atribute (podaci o kupcu, adresi, bla bla ..) , zatim ima
i neka svoja poslovna pravila (adresa mora biti popunjenja, poštanski broj tačan ....)

Faktura ima i svoje stavke, svaka stavka ima opet neke svoje atribute i poslovna pravila.
(Vrsta robe, cene, količine, mora biti unesena količina ....)

Ovakva hijerarhija je uspostavljena zbog toga što se u modelu insistira na jednostavnosti objekata, tj.
da se svaka klasa dizajnira da ima što uže definisanu "zonu odgovornisti".

Možda ovako mogu malo bolje objasniti ideju.

Celu fakturu sa sve stavkama možemo strpati u jednu ultra giga mega klasu u kojoj će se
nalaziti sve, od svih mogućih polja do svih mogućih poslovnih pravila, do toga kako sve to pisati čitati u nekoj
bazi podataka ili gde već hoćeš. I to će da radi ...

Iz aspekta održavanja i preglednosti ovo je noćna mora.
Teško se menja, za šta god da se uvatiš, ili će da budžiš, ili ćeš poželeti da pišeš ponovo.

Dok u ovom našem slučaju imaš Fakturu koja vodi računa o svojim atributima i svojim poslovnim pravilima i koja
zna kako da se upiše u bazu podataka i tačka. (O stavkama (tj. deci) treba da zna samo kako da ih učita iz baze)

Zatim imaš stavke fakture koje opet znaju da vode računa o sebi - atributi, poslovna pravila, perzistencija ....
Stavke nisu niti treba da budu svesne o postojanju fakture, znači totalno nezavisne klase - (docoupling)

Ima više klasa, ali je sve nekako na svom mestu, svaka klasa ima samo jednu funkcionalnost.
Ne moraš da brineš da recimo dok si prčkao nešto po stavki da nisi razvalio nešto drugo ....

Inače, kad je OOP u pitanju, čim primetiš da ti se klasa komplikje, tj. počinješ da je budžiš, to je dobar
znak da treba da staneš i da preispitaš dizajn.

CSLA nudi svoje stereotipe klasa (EditableRoot, EditableChild, EditableList) kao dobre temelje za dizajn
kvalitetnog objektnog modela (poslovne) aplikacije.



Što se tiče pitanja oko dropdown liste i primera sa vrstama stanja vozila odgovor je pod dva tj. treba
više klasa iako to na prvu loptu izgleda malo "naopako". Trebaju ti "čak" tri (dve) klase.

- Za ažuriranje vrsti stanja vozila treba ti jedna EditableRoot klasa
- Za dropdown listu ti trebaju ReadOnlyRootList + ReadOnlyChild, (mala digresija: za drop down ili lookup je zgodnija NameValueList klasa)

Moglo bi sve to da se strpa i u jednu klasu i da radi ali:

Jedan editable root, zahteva mnogo više resursa u odnosu na readonly objekte.

Konkretno, svaki put kad unosiš novi automobil uvek će ti trebati dropdown lista.
Podaci za tu dropdown listu su prilično statični - retko se menjaju/dodaju.

Mnogo je jeftinije imati "lightweight" readonly klasu za "svakodnevnu" upotrebu, dok ti je na
raspolaganju i EditablerRoot klasa kad treba da se i ažurira.

Imamo više klasa, ali to u ovom slučaju i jeste željena posledica. Svaka od tih klasa radi upravo
ono za šta je namenjena na najbolji i najoptimalniji način.
EditableRoot - Ažurira podatke za listu, ReadOnly .... prikazuje podatke.

Takođe obrati pažnju da je CSLA dizajniran da bude i skalabilan (to je ono "S" u CSLA) - moguće
je da promenom jednog parametra celu aplikaciju prešaltaš iz 2 tier modela u 3 tier ili 4 tier model.
Kada objekti počnu da trčkaraju po mreži resursi postaju itekako bitni.

Količina klasa u ovom slučaju i nije neki problem, jer (bar po mom skromnom mišljenju)
uz ovakav framework, neki code generator se manje više podrazumeva.

Nadam se da sam uspeo bar malo da ti pomognem.

Potrebno je malo više vremena i praktičnog rada kako bi ti sve "leglo".

Po mom mišljenju, trud za savladavanje CSLA se višestruko isplati, mnogo toga sam
naučio baveći se njime.

Ima tu još koječega i verujem da ćeš kako budeš dublje gazio imati sve više i više pitanja.
Pitaj dalje, pa ako stignem videću da ti pomognem koliko god mogu i znam.
Imaš i izuzetno aktivan i kvalitetan forum na sajtu, a i Rokijev blog preporučujem.

Pozdrav,
Bojan

Stvar izgleda veoma zanimljivo, hvala i OP i vbbojanu. Nisam ni znao da je neko vec lupao glavu oko svega toga. Izgleda da na osnovu CSLA business frameworka bez većih problema može da se napravi i potpuno generički UI tj. View layer, jer klase imaju sve što ima treba da same sebe opišu.

Upravo tako, genericki UI se da napraviti bez problema.
Kad uđeš u štos i napišeš par generičkih UI elemenata,
kreiranje UI postaje krajnje brzo i jednostavno.

Generalno, kad jednom savladaš principe i logiku frameworka,
dodaš na to jedan code generator, produktivnost neverovatno
skače, da ne pričam o visoko i kvalitetno organizovanom kodu
koji je kasnije lak za održavanje ....

Drago mi je da ima još zainteresovanih.

Pozdav
Bojan