Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Krtek + Krtek 03. 08. 2012, 13:40:08
-
Zdravim,
chystam se na jeden projekt (webova applikace v Jave), pricemz pro tuto aplikaci budu mit nekolik zakazniku v radu jednotek (5 - 10 zakazniku). Pro kazdeho zakaznika bude aplikace bezet na jemu vyhrazenych serverech (tyto servery budu mit ve sve sprave ja, zakaznici budou pouzivat pouze danou aplikaci). A jedna se mi o to, co je "best practice" pro vyvoj takoveto aplikace, kde priblizne 90% kodu bude spolecneho pro vsechny zakazniky a tech zbyvajicich 10% kodu budou specifika jednotlivych zakazniku.
Zajima me treba jak se nejlip popasovat s drobnymi odchylkami databazoveho schematu (napr. nutnost pro nektereho zakaznika evidovat navic nektere attributy urcitych entit z duvodu mistni legislativy apod.). ORM framework chci pouzit JPA z cehoz vyplyva urcita zavislost Javovskych trid mezi sebou. Moje idea zatim je takova, ze pro tech specifickych 10% kodu na zakaznika bych narval do oddeleneho jar souboru, pricemz pri deployi aplikace pro daneho zakaznika by se takto pribalil jeho specificky jar soubor.
Na buildovani projektu chci vyuzit Maven a pocitam ze s vyuzitim profilu by toho mohlo jit dosahnout.
Dalsi vec je repository se source codem (svn?, git?) a bug fixing, pripadne vytvareni novych features prave v te spolecne casti kodu? Vidite zde nejaka uskali a ktery z danych nastroju je podle vas vhodnejsi? Bohuzel ja sam mam zkusenosti pouze s svn, takze nemuzu moc porovnavat.
Diky za odpovedi.
-
javu neznam, reknu jedine: svn pro novy projekt je nesmysl (pokud to nema dlouhodobou historii ve firme, napojeni na infrastrukturu a tak.)
-
Jak to nejlíp řešit v javě neporadím, ale co se týče VCS, v gitu se branchování, mergování apod. dělá hodně dobře, včetně rebase a cherrypick* a díky jednoduchosti formátu je to krásně přehledný.
Se SVN porovnat neumím, ale git mi přijde jako hodně dobrej nástroj, se kterým se pěkně pracuje, včetně případnýho ručního vrtání se v jeho vnitřnostech (v případě, že nevím, jak něco udělat automaticky, potřebuju něco ručně opravit atd...).
Myslím, že s GITem neprohloupíš :)
*
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
-
S tím programováním je to vždycky těžký. Záleží na tom, jak moc se toho liší mezi těmi klienty. Pokud je to alespoň v jedné specifické oblasti, tak by to mělo být v pohodě. Pokud se každý bude lišit v něčem jiném, tak jsi v pytli.
Jinak to s těma jar-kama je podle mě správná cesta. Konkrétní implementace záleží na tom, jestli se liší v nějaké službě nebo mají specifickou celou část od DB po View. Takhle bez dalších informací se nedá víc říct.
-
ja jsem obcas donucen neco s SVN delat, bohuzel :o . uz ve dvou vyvojarich mame obcas problem. s gitem je to uplne jinde.
-
Pokud zacinas, tak bych doporucil git. Na verzovani db schematu se poduk mozno vykaslej. Je to spousta prace a navic budes muset resit modifikace stavajich dat, pri zmene DB struktury. Urcite si usetris spoustu casu pokud navrhnes DB schema dostatecne univerzalni aby mohlo slouzit vsem zakaznikum najednou.
-
Tak na git jsem slysel/cet spoustu chvaly oproti svn, takze se v nem chci trochu pohrabat tak jako tak (diky za linky, kouknu na to).
Co se db tyka, tak pocitam, ze velka vetsina struktury dat bude spolecna, nimene jak jsem psal, z duvodu mistni legislativy ocekavam drobne rozdily v podobe sem tam nakyho atributu na tabulku navic. Pak se totiz nejedna jen o tu db, ale souvisi s tim i "drobna" odlisnost ve view (nejake fieldy navic ve formulari, jejich validace apod. + sem tam nejake to tlacitko navic pro urciteho zakaznika). Ale ocekavam opravdu odlisnost jen v detailech. Jelikoz se dany projek teprve chystam vytvorit, tak by me prave zajimalo predem jak se vyporadat s temito drobnymi odlisnostmi pro urcite zakazniky, jak nastavit strukturu projektu, abych s tim uz pocital dopredu, protoze ty odlisnosti urcite vzniknou, a nesnazil se to nejak haluzove napasovat pozdeji az teprve vznikne nejaky problem.
Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..
-
Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..
Jestli jsou rozdili takhle trivialni, tak drz kod spolecnej - bude umet vsechno a pro konkretni zakazniky budes featury disablovat compile-time nejakym "#define" (ja vim, java), pripadne parametrem v nastaveni.
-
Tak na git jsem slysel/cet spoustu chvaly oproti svn, takze se v nem chci trochu pohrabat tak jako tak (diky za linky, kouknu na to).
Co se db tyka, tak pocitam, ze velka vetsina struktury dat bude spolecna, nimene jak jsem psal, z duvodu mistni legislativy ocekavam drobne rozdily v podobe sem tam nakyho atributu na tabulku navic. Pak se totiz nejedna jen o tu db, ale souvisi s tim i "drobna" odlisnost ve view (nejake fieldy navic ve formulari, jejich validace apod. + sem tam nejake to tlacitko navic pro urciteho zakaznika). Ale ocekavam opravdu odlisnost jen v detailech. Jelikoz se dany projek teprve chystam vytvorit, tak by me prave zajimalo predem jak se vyporadat s temito drobnymi odlisnostmi pro urcite zakazniky, jak nastavit strukturu projektu, abych s tim uz pocital dopredu, protoze ty odlisnosti urcite vzniknou, a nesnazil se to nejak haluzove napasovat pozdeji az teprve vznikne nejaky problem.
Ok, abych to trochu zkonkretizoval, tak uvedu priklad, kterej me ted rychle napadnul:
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo).
No, a ted mi jde o to, jak se jednoduse vyporadat jednak v Jave a jednak v gui (html) s timhle drobnym rozdilem v podobe rodneho cisla. Nedej boze, abych mel zakaznika C, kterej potrebuje evidovat osoby (jmeno, datum narozeni a taky rodny cislo, ale uplne jinej format rodneho cisla nez zakaznik B).
Je to sice rozdil pouze v jednom jedinym atributu, ale ma to vliv jak na Javovej kod, tak na generovani html vystupu, tak na validaci vstupnich dat od uzivatele. Fakt mi z toho jde hlava kolem a moc nevim jak se s tim poprat, abych se do toho zbytecne moc nezamotl..
Pokud jde o neco takovyho tak bych - alespon na neco - doporucil pouzit EAV. Zvlast jestli ta DB bude mala.
Takze budes mit tabulku PERSON s pevnyma sloupcema a pak tabulku CUSTOMER_PERSON_DETAIL
kde bude "PERSON_ID", "DETAIL_NAME", "DETAIL_VALUE". Dulezity je aby ty pridavny atributy nebyly soucasti PK ani FK.
Jakmile budes mit u ruznych zakazniku ruznou verzi DB schematu tak se z toho drive nebo pozdeji zblaznis.
Po par aktualizacich uz ani nebudes tusit, v jakym poradi jsou ktery sloupecky u kteryho zakaznika.
Videl jsem i systemy, kde se DB schema generovalo primo z objektoveho modelu aplikace. Po par letech to ale vetsinou skouncilo.
Jakmile mas v produkcni databazi nekolik GB dat, tak musis zmeny ve schematu resit "rucne" a chytre - zadny tool ti nepomuze.
-
Mam dva zakazniky A a B. A potrebuje evidovat osoby (jmeno, datum narozeni). B potrebuje evidovat taky osoby (jmeno, datum narozeni a rodne cislo)...
Udělej si další tabulku, do které si uložíš konfiguraci daného zákazníka. Ve Factory si nejprve načteš tuto konfiguraci a podle ní vyrobíš ty správné objekty.