Üdv!
Van egy "érdekes" problémám/ánk. A helyzet a következő, réges-régen elkezdtünk egy projektet fejleszteni akkor még Struts alapokon, később a Spring is bejött. Aztán szép lassan, ahogy jöttek a megrendelések más cégektől a projekt szétbomlott modulokra és ezeket a modulokat újra hasznosítottuk más projektekben.
Most ha van egy új cég akik megbíznak minket, úgy néz ki a dolog, hogy szépen fogjuk csinálunk a cégeknek egy backend és egy frontend modult és a CVS-ből behuzzuk azokat a modulokat amikre szüksége van az adott ügyfélnek.
Példa:
Kati nyit egy virágboltot, szeretné ha tudna számlázni, virágot szállítani és megrendelést felvenni. Akkor neki kell a számlázás modul, a szállítmányozás modul és a megrendelésfelvétele modul. Egy modul valójában mindig két modult takar, mert minden mondulnak vagy egy frontend és egy backend része.
Pisitike az új ügyfél nyit egy turbórágó boltot és szeretné ha tudna számlázni, de az árút csak helyben lehet átvenni, mert elolvadna mire kiszállítaná, korszerű hűtőberendezésre meg nincs pénze. :)
Tehát neki csak a számlázás modul kell.
(Direkt nem autós!)
És itt jön a bibi, a számlázós modul a CVS Head repojába található, ha most az új Pistike workspace-be ki check-eljük és elkezdjük módosítani az üzleti logikát meg a frontendet, akkor amint commitoltuk az újításokat Katinak az oldala tönkremegy, mivel ugye ő is ezt a modult használja..
Sajnos beleestünk abba a csapdába, hogy újra akarunk hasznosítani, viszont mikor jön a projektvezető, hogy de jó lenne ha ez a gomb nem ott lenne hanem itt, vagy kéne pár új input mező, akkor nem mondhatjuk neki, hogy sajnos ez nem megoldható, mert akkor Katinál is megjelennek az új mezők. Ezért arra, gondoltunk, hogy minden mondulba lesz egy default kinézet, konfig és amikor kapunk egy új megbízást, akkor a szükséges modulokat ki checkelve a build script fogja és szépen ezt a default modulkonfigot áthúzza a megbízó backend és frontend monduljába (JSP-stől, CSS-estől kezdve mindenig). Ekkor ott már kedvünkre változtathatjuk a dolgokat, mert ügye ez projektenként változó. Az alap modulokra mégis azért van szükség, mert a Java osztályokat meghagyjuk ott és az egyedi modulba csak kiterjesztjük azokat és úgy változtatjuk.
Most így néz ki egy JBoss deploy:
kati_projekt.ear
|
|--Application_kati_Backend.jar
|--Application_kati_Frontend.war
|
|--Module_Szamlazas_Backend.jar
|--Module_Szamlazas_Frontend.war
|
|--Module_Szallitas_Backend.jar
|--Module_Szallitas_Frontend.war
|
|--Module_Megrendeles_Backend.jar
|--Module_Megrendeles_Frontend.war
pistike_projekt.ear
|
|--Application_pistike_Backend.jar
|--Application_pistike_Frontend.war
|
|--Module_Szamlazas_Backend.jar
|--Module_Szamlazas_Frontend.war
A jelenlegi problémák között található pl az, hogy minden modulnak külön session-je van. Ezért ha átlépsz egy modulból egy másikba, ott nem lesz meg az, hogy te most éppen be vagy jelentkezve vagy nem. Ezért a JBoss SSO-jat használjuk, de ez annyira nem jó nekünk. Akkor például, ha valaki nyelvet vált az egyik modulba és a sessionbe letároljuk, hogy az aktuális nyelv kínai, akkor modult váltva megint vissza fog ugrani a nyelv az alapértelmezettre, mert az ottani session-be ez nincs lementve.
A merge-elés ezt is megoldaná, de ez még csak egy felvetés, a megvalósításról eddig nem sok szó esett. Olyan gondok is vannak, hogy akkor, hogy lesz megoldva a Spring konfig fájlok használata, mert ugye most minden mondulba külön web.xml van és külön akarmi-servlet.xml.
Egy másik gond, hogy az egyik modul még Struts 1.1-el üzemel. Ami enyhén szólva is brutális, olyan táblázatokat generál a Struts taglib, hogy ember legyen a talpán aki azt CSS-el megformázza, ezt a modult szeretnénk migrálni Spring-re, de az is elég sok bonyodalmat okoz.
A kérdésem, hogy ti hogy oldjátok/oldanátok meg ezeket a problémákat, van-e erre valami bevett szokás?
szerk: Úgylátom valaki már találkozott pont ugyanezzel a problémával. Az egyetlen különbség, hogy mi Ant-ot használunk.
- 1417 megtekintés
Hozzászólások
Frontend szinten így nem lesz soha modulrendszerű. Ha portálban és portletekben gondolkodok, akkor a különféle ügyfelek különféle igényeit le lehet képezni egy-egy újabb portletben, amelyek külön weboldalakat használnak a külön igényekre és közös weboldalakat a közös dolgokra. A backend-et pedig érdemes közösen tartani, mind business function rétegre, mind a DAO rétegre.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
- A hozzászóláshoz be kell jelentkezni
git,hg - repo cloning, vagy branch.
svn - modul masolasa a masik repoba
Pont a CVS-re nincs igazan jo megoldas, ezt megszivtatok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
De azért van egy közös modul, mert ha van valami fejlesztés vagy bugfix, azt ugye kijavítjuk a modulba és akkor az mindenhol "ki lesz javítva".
- A hozzászóláshoz be kell jelentkezni
Ne CVS-t használjatok, hanem SVN-t vagy bármi még modernebbet.
Tanuljátok meg rendesen használni (branch, patch, backport, stb...)
Csináljatok egy sereg teszt-esetet, hogy a backportolások hibáit automatikusan ki tudjátok szűrni.
Nézz utána annak, mi is a continuous-integration.
Más: vagy patchelsz, vagy override-olsz.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Ezt git branch-ben is meg tudjatok csinalni, es ott meg intelligensen mergelni is tudtok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Most köcsög troll leszek, igen, de ezért nem szokott senki refaktorálni, csak beszélni róla...
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy a programozó ott gányol,ahol tud, és egyébként is lusta, és mindig a legkisebb ellenállás felé halad. Az igazi refactoring arról szól, hogy minden ugyanúgy működik mint előtte, tehát visszafelé kompatibilis, ezért olyan nagyon nehéz.
- A hozzászóláshoz be kell jelentkezni
Hát igen...
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Üdv,
- cseréljétek le a cvs-t svn-re vagy jobbra
- gondoljátok végig az architekturátokat, mert ahogy olvasom, eredetileg nem arra lett kitalálva, amire használni akarjátok
- nézzétek át a keretrendszert, amit használtok, mert ez a modulok közötti váltásnál eltűnik a session, nem a jó keretrendszer választásának jele :)
- fent említette valaki a portlet-eket, nézzétek át (LifeRay kezdetnek pl.)
- a refactoring pénzbe és időbe kerül, azt számoljátok bele, viszont ha belekezdetek, akkor már úgy csináljátok meg a mögöttes logikát, hogy lehessen automatizálva tesztelni. Ezzel a kódminőség/megbízhatóság is drasztikusan növekedni fog
- A hozzászóláshoz be kell jelentkezni