Verzioniranje klasa

cSubject1, cSubject2... Bojim se pitati što zapravo piše u UMLu...

Pa što ne bi bilo lakše držati onu aktualnu cSubject, a ovo ostalo cSubject_legacy, cSubject_v2.3, cSubject_old, cSubject_rollback

Ovo 1,2,3,77 ne govori što ta klasa (metoda, što je to već?) radi i kod postaje nečitak.

A nije mi baš jasno kod ovog primjera, što i zašto pretvarate u int? Jel imate nešto ovako

--id--id_subjekta--naziv--broj--id_grad--id_država--

--3--2--Ivana Gundulića--54a--31--12--

???

I sad ovi IDi su u varchar[50], a vi ih pretvarate u int?

Mislim ako sam ja dobro shvatio, vi radite alter table, s time da pišete paralelne klase tako da aplikacija koja stoji nad DB (WH) može raditi i sa starom verzijom i sa trenutnom i sad odjednom imate špageti kod u kojem se ni vi sami ne snalazite? 

Uf neće biti dobro, mislim da je primjer s ulicom najbanalniji. Što će se dogoditi ako se doda u tablicu neko novo polje, tj. napravi se nova tablica za novu verziju. E sad jedan korisnik unosi bitne podatke u jednu tablicu, a drugi u drugu s drugom aplikacijom. A informacije moraju biti dostupne i jednoj i drugoj aplikaciji. E sad da bi to radilo tj. ostalo sinhronizirano napatiti ćete se s triggerima i taskovima za sinhronizaciju. Nakon par verzija nečete znati što je što.

Recimo da imate 10 aplikacija. I netko s prvom verzijom nešto promjeni, to znaći da se ostalih 9 mora sinhronizirati s prvom verzijom tablice/app. Triggeri na prvoj tablici, popune drugu, triggeri na drugoj popune treću, a i suprotnom smjeru. ili ako netko mjenja 4 verziju, mora se sinhronizirati s višim i nižim verzijama tablice. Uf.

Ili aplikacija verzije 10 ima assemblije od 1-10. i poziva specifične funkcije za svaku verziju, al verzija 6 nije svjesna viših verzija.

Još jedan uf. Pretpostavljam da koristite SQL Server, možda vam pomogne njegova opcija (nisam siguran kako se to zove) stavljanje asemblija u bazu i pozivanje njihovih funkcija iz klijenta. Možda bi tako u svakom trenutku sve verzije bile svjesne ostalih verzija aplikacija. Mislim da i Oracle ima nešto slično za Javu.

Iz ovoga što si reko - baza nije normalizirana. Što vi više prtljate po njoj (a da to nije normalizacija), to je veća vjerojatnost da će se pojaviti anomalije. Ak se one pojave, ode sve u...

Neke stvari nismo smjeli normalizirati zbog izričitih zahtjeva klijenata. Dakle, ako oni žele unijeti npr ulicu "Žrtava fašizma" kao "Ul. Žrt. Fašizma", "Ulica žrtava fašizma", "U. Ž. Fašizma", "Ulica Ž. Fašizma" i sve druge kombinacije, morali smo se složiti. Idiotarija, ali kad pričaš s ljudima koji i dan-danas rade na crno-bijelim terminalima onda znaš da nema puno smisla pričati im o normalizaciji.

Ma nije to hack, takve stvari su mi kao "dobar dan". Ali postojanje n različitih verzija iste stvari (klase) i sve to u istom projektu... ne znam.

 Ne znam o kakvoj je aplikaciji rijeć pa ne mogu komentirati. Al znam da svaki put kad otiđem, jednostavno imam potrebu da bacim oko u čemu rade. I od osobnog bankara do tete za pultom redovito koriste web aplikacije.

 Lol, monokromatski terminal u Silverlightu :-). San svake Štefice.

Sorry, dečki, bio sam na sastanku sa klijentima...

Dakle, nije kompletan sustav za bankarenje - radi se o jednom dijelu (dosta opširnom). Nadalje, naša aplikacija nije crno-bijeli terminal nego klasična win forms aplikacija. Naši klijenti su uglavnom naviknuti na spomenute terminale, zato sam to napisao.

Nisam siguran kako bismo sa naslijeđivanjem mogli riješiti spomenuti problem. Jer srž problema je da se postojeća klasa mijenja a treba nam nova klasa koja se isto zove a ima različit set funkcionalnosti i property-ja. I tako za svaku pojedinu promjenu (istog entiteta) - nove tablice u bazi, nove klase, nove forme, novi reporti... I onda kad klijent zatraži određeni zapis iz baze mi trebamo znati što moramo instancirati ovisno o nekakvoj oznaci verzije zapisa. A kao što sam spomenuo - klase su nam vrlo velike, set business pravila je poprilično opširan, ima puno računanja i vrlo malo tolerancije za grešku.

EDIT: da, imamo i nabrijane grafove!

Nisi me shvatio. Ne radimo copy/paste sada i nemamo više različitih (aktivnih) verzija iste klase. Stvar je u tome što gazda INZISTIRA da to počnemo raditi. Dakle, ako imamo klasu cDokument i klijent zatraži da se u toj klasi nešto promijeni (ili na formi) mi bismo trebali napraviti novu verziju klase cDokument koja će se ISTO (!!!) zvati i koja će instancirati svoju formu radi prikaza tih podataka a koja će koegzistirati sa već postojećom klasom cDokument i sa postojećom formom koja te podatke trenutno prikazuje.

Čini mi se da nisam dobro objasnio problem.

Kako bi ti riješio problem sa promjenom tipa određenog property-ja na klasi (koja je BASE klasa nekim drugim klasama)? Dakle, imaš nekakav public property tipa int i trebaš ga promjeniti u string. A da se nova klasa ISTO zove, da se snima u svoju tablicu (što samo po sebi nije problem jer klasa ima svoje metode za snimanje i brigu o business pravilima) i da onda nakon 10 različitih izmjena možeš sve te podatke koji su "istog" tipa prikazati zajednički u nekakvom gridu i da nakon ohoho vremena možeš to bez problema trpati u isti cube pazeći pri tom na slowly changing dimenzije. I onda to tako sa još hrpetinom još puno kompliciranijih slučajeva? Inheritance brine o takvim stvarima ali ja stvarno ne znam kakav bih inheritance napravio da imam dvije različite klase sa potencijalno drastičnim razlikama u strukturi koje će biti istog tipa. Znači, imam klasu cDokument koja ima 2 int property-ja i 2 string property-ja. I onda imam jednu drugu klasu cDokument koja ima 6 int property-ja, 4 string property-ja i jedan byte[] property. I onda nekada trebam provjeriti nekakav objekt na ovakav način - If(obj is cDokument)... Pa kompajler će me stjerati znaš gdje, ne?

a cemu mu sluze podaci ti zajednicki podaci ? sta ce on da dobije iz toga :S ... ne vidim smisao zajednickog koegzistiranja nove klase i stare.. ako se desi npr 10 promena, to je 10 novih formi, zakomplikovat ce se sam layout programa, da ne pricam dalje... pogotovo ako klijent trazi promenu, logicno je da nece vise da koristi staru verziju, jer mu ocigledno ne odgovara... kao post iznad, OTKAZ GAZDI :)... Jedino sto meni pada na pamet, jeste da se koristi nekakvo genericno resenje, odnosno da funkcionalnost formi bude genericka...da ona zna raditi sa bilo kojom klasom, odnosno tabelom u bazi... jedino je problem neku vecu funkcionalnost koja se trazi da bude genericna..

Da, naravno ali gazda inzistira da ti podaci budu netaksnuti i da se učitavaju na IDENTIČAN način kako su se učitavali sa verzijom sa kojom su unešeni! Ma boleština...

Vlasnik firme u kojoj radim!

On daje placu. Njegova je zadnja.