Subject: RE: [JavaTech] riport (j2ee flame :)

From: "Viktor Szathmary" <[email-masked]>
Date: Thu, 15 Nov 2001 10:51:17 -0500

hi,

> >es ha mar a j2ee "egyszerusiteseinel" tartunk, szerintem az sem teszi
> >jobba az egeszet, hogy mondjuk egy bean home es remote 
> implementaciojat
> >ugyanabban az osztalyban kell eszkozolod - csak eppen mas elvek
> 
> Ezt kifejtened?
> Homenal csak interfacet definialok, az appserver irja meg nekem az
> implementaciot annak fuggvenyeben, hogy milyen protokollt hasznalok

elnezest, nem voltam preciz a megfogalmazassal, valojaban nem a home es
a remote implementaciorol beszelek, hanem a bean implementaciorol :)

mondjuk egy BMP entity beanrol van szo... ugy vettem eszre, hogy a
tapasztalatlanabb programozokat megteveszti az hogy pl egy
ejbFindByAkarmit meg mondjuk az akarmiBusinessMethod-ot ugyanott kell
implementalni.. pedig nincs igazan kozuk egymashoz: a biz method a bean
peldanyon operal, mig a finder termeszetesen NEM (de persze kell hozza
egy bean objektumpeldany amin meghivhatja :) - csak epp a Sun ide
sikeritette.

ez nem nagy gond, de szerintem tisztabb lett volna ha nem keverik egy
osztalyba a ket dolgot... meg ha mar igy van akkor minek ez a naming
convention az "ejb" prefixszel, amikor a biz methodusokra nem terjed
ki...

szoval nincs baj az EJB-vel, mindenki orul neki nagyon, viszont lehetett
volna elegansabban is sokmindent.. :)
egy elegans APIval egyreszt orom dolgozni.. masreszt vegyuk a
hatekonysagot :))) tegyuk fel hogy 20 percet kell azzal tolteni, hogy
megertessem a programozoval a fenti dolgot (vagy kijavitsak vmit amit
elrontott mert nem tudta)... a programozo meg a magyarazo orabere legyen
olcso, 20 ill 40 USD :)) akkor ez a 20p 20 USD. ha mondjuk 100.000 EJB
projekt van a vilagon, akkor az mar 2millio USD... :) szoval ilyen
skalan mar szamit, hogy mennyire elegans egy API :)) vegyuk csak a win32
api-t.. eheh :))

	viktor

---

From: Szitas Krisztian <[email-masked]>
Date: Thu, 15 Nov 2001 17:28:14 +0100

Aha, ertem mire gondolsz, 
en viszont igy gondolkodnak ebben az esetben:

Ha ketteveszem a a Bean paldanyon dolgozo methodusokat,
es a Bean megkeresesere/megkrealasara vonatkozoaknak
az implementaciojat, akkor azt a penzt amit a magyarazaton
esetleg megsporoltam 2x elvesztem azaltal, hogy
az adatforras elereset ketszer kell lekodolni, azaz tobbszor
hibazhatok, es X orat debugolassal kell toltenem, 
foloslegesen nagyobb lesz a kodom is, ha valamit javitanom kell
2x kell javitani, leforditott bytekod is nagyobb lesz.

Kulonben ez nekem eddig olyan nagyon fel sem tunt, mert amugy is
kulon fileokban voltak nekem a perisztenciat vegzo es a business
methodusok. CMP-nel meg amugy is csak BL methodot ir az ember,
ott nem is latja a load-ot, meg creat-ot.

"ejb" prefix reszre meg annyit, hogy v2.0 felett mar az entityBeanben
hasznalhatsz home methodokat, amik nem egy instance-on mahinalnak,
ott direkt jol jon, hogy nem terjedt ki, szerintem amikot az 1.0 anal
megalkottak, mar selytettek valamit a fiuk.

Ha van meg valami elegansabb temakoros panaszod, szerintem nyugodtan tedd 
fel, hatha egyutt kitalaljuk, hogy mit miert csinalhattak.

dAb

---

From: "Viktor Szathmary" <[email-masked]>
Date: Thu, 15 Nov 2001 11:57:32 -0500

hi,

> 2x kell javitani, leforditott bytekod is nagyobb lesz.

namost...
- jo esetben az adatforras elereset valami egysegesebb helyre rakod
amugy is, hiszen tobb bean is feltehetoleg el fogja erni ua forrast.
- a kod nem lesz nagyobb, csak annyival amennyit az extra class headerje
elfoglal (parszaz byte? :)
- nem kell ketszer javitani, ugyannyi kod lenne igy is, csak egy masik
classban..

de mondom, nem vagyok vallasos ez ugyben, csak egy aprosag, ami eszembe
jutott :)

> fel, hatha egyutt kitalaljuk, hogy mit miert csinalhattak.

jo, majd meg biztos eszembe jut egy par... :))
pl. tovabbra is zavar, hogy nem lehet metodusok visszateresi erteket
specifikusabbra venni egy subclassban :))
az 1.5-ben elvileg benne lesz majd Generic Java, de hat azt is lehetett
volna szebben csinalni, ha az elobb emlitett override mukodne javaban :)
de errol mar volt szo... :)

	viktor

---

From: Szitas Krisztian <[email-masked]>
Date: Thu, 15 Nov 2001 18:11:32 +0100

>- nem kell ketszer javitani, ugyannyi kod lenne igy is, csak egy masik

ja, valami helper resource locatorral meg lehet oldani a problemat, igaz

Magambol indultam ki, es en nem egyszerusitem le a beanjeimet egy rdbms-bol
dolgozora, igy egy Factory patternnel ki kell keresgelnem altalaban a
deployment
decsriptorban beallitott adatok alapjan a datasourceimat es legyartani a
DAO-t,
es meg nem birtam egy helper osztalyba osszerakni az ehhez tartozo osszes 
funkciot, majd egyszer ha lesz kedvem megint kodolni, meg rajovok hogyan
kellene, akkor lehet hogy atgondolom ezt a fajta nezopontot megint.

---

From: "Viktor Szathmary" <[email-masked]>
Date: Thu, 15 Nov 2001 12:15:38 -0500

hi,

> decsriptorban beallitott adatok alapjan a datasourceimat es 
> legyartani a DAO-t,

mondjuk en rdbms-be dolgozom az igaz, de ettol fuggetlenul a deployment
descriptorbol veszi azt hogy mihez kell kap

---

From: "Viktor Szathmary" <[email-masked]>
Date: Thu, 15 Nov 2001 12:17:02 -0500

hi,

mondjuk en rdbms-be dolgozom az igaz, de ettol fuggetlenul a deployment
descriptorbol veszi azt hogy mihez kell kapcsolodnia... (az iment tul
hamar nyomtam ctrl-entert :)

meg mas beanekben (SBk) jms queuekhoz kell kapcsolodni, ott is probaltam
kivenni az queuek elereset a beanbol, jot tesz az :))

	viktor

---

From: Szitas Krisztian <[email-masked]>
Date: Thu, 15 Nov 2001 18:23:59 +0100

>descriptorbol veszi azt hogy mihez kell kap

de akkor is el kell meg vele jatszadoznod, hogy ha rdbms, akkor most az
oracle vagy interbase vagy db2.
meg tudtad ezt valahogy normalisan oldani?
definialtal megegy flaget a dd-ben, ami segiti a dao kreaciot,
vagy szamitasz ra, hogy rdbms jon vissza, es ott a vendorname/verzioszam
alapjan probalod kitalalni hogyan hasznald a daot?
(pl like joker karakter micsoda)