EJB gond

Nekialltam en is a a J2EE-nek. Szep, jo, egyetlen gondom, hogy a dependency injection nem akar menni.

Hozzászólások

Próbáld meg a Netbeans-ben kikapcsolni a directory deployment-et, az szokott hasonló felderíthetetlen problémákat okozni. (asszem vhol az appserver beállításoknál kell kapcsolni és alapértelmezetten be van kapcsolva).

Mint fölöttem is leírták, a jó megoldás egy facade bean bevezetése. Esetfüggő, hogy maga a facade session scope-ba kerül, vagy nem.

Viszont miért is írunk kódot JSP -ben? Tudom, hogy a kék könyvekben is ez van, meg egy rakás cégnél is így csinálják, de ma már van olyan, hogy MVC, sőt továbbmegyek, van egy rakás egyéb megjelenítési technológia, a különféle framework-ökről nem is beszélve.

Elsírom magam, amikor úgynevezett architect-ek összeraknak egy multitier alkalmazást aztán nekiállnak .jsp -re ráengedni a requestet meg onnan EJB-t hívogatni. A felmerülő problémákra meg kitalálnak gyorsan 20 féle business patternt, business delegate, session facade, stb. Úgy hallottam, ezen a fázison már a jobb PHP kóderek is túljutottak.

Ps. ez nem neked szól, látom, hogy friss hús vagy.

Nem akarok JSP-zni egyaltalan amugy, csak gondoltam kiprobalom, hogy ez hogy is mukodik. Sosem art legalabb minimalis szinten tisztaban lenni a leheto legtobb dologgal. Igazabol nem is szamitottam arra, hogy ott programkod lesz. Es a tutorial peldaban valoban ott van beagyazva a java kod a jsp-be...
A frameworkoket meg mar kozben nezegetem, persze igy eleg nehez kivalasztani az n+1-bol, hogy melyik a bevetesre erdemes.

Amiket ki fogok probalni igy elso ranezesre:

Persze lehet mindegyik nagy mellefogas, de valahol el kell kezdeni :)

Attol mit varsz el tolik. A Tapestry es a Wicket komponens keretrendeszerek, foleg web resszel foglalkoznak (keresek kiszolgalasa, viewok feltoltese adatokkal), mig a Spring egy komplett alkalmazas platform lehet, ahogy ok mondjak egy jee alternativa. Ha megerted a mogotte huzodo filozofiat, akkor egy nagyon kenyelmes, es hatekonyan platformot kapsz kezbe.