Jeg har x antal JSP sider der henter informationer fra diverse Entity Bønner. Lige pt. laver hver JSP side jeg har et lookup til en bønne, henter informationer fra databasen og viser disse på JSP siden. Jeg har dog overvejet at lave en starklasse der laver et lookup på alle mine entity bønner(7 ialt) henter alle informationer fra disse bønner og gemmer dem i X antal Arrays. Når jeg så har en JSP sider, der skal have data fra "databasen" kalder de bare min startklasse og henter disse data via en getMetode i klassen. Derved undgår jeg at når jeg hver gang kommer ind på min JPS side at lave et lookup.
Mit spørgsmål er, er dette en god løsning, eller er det bedre at lade hver JPS side have sin egen lookup. Hvad er det bedste rent performance mæssigt.
Jeg går udfra, at du stadig benytter EJB 1.1 ...... Ved at bruge EJB 2.0, vil du lige netop kunne løse problemet med langt bedre performance. I dit tilfælde, vil jeg nok lave en Session Facade med adgang til Entity-bønnerne. Dine JSP-sider skal dermed kun kalde ind på Session-bønnen. Endvidere vil jeg nok også benytte mig af Value Object Pattern, hvor Value Objects indeholder de data, som skal vises på klienten. VO'erne kan du så bygge på Session-facaden, som skal indeholde data samlet ind fra dine Entity-bønner.
Ja jeg benytter EJB 1.1 er desværre tvunget til det pga. udviklingsværktøjet. Jeg har lavet en fasade med adgang til mine entity bønner. Det er godt nok en session bønne men en almindlig java klasser. Kigger lige engang på value Object patteren. Det jeg i øjeblikker har er min Java klasser der indeholder Arrays der indeholder de data som jeg skal have vist på klienten. Jeg sparer jo også at lave lookup hele tiden samt min adgang til database foregår kun en gang. Kama findes der nogel links til Value Object Pattern ?
Jeg er ganske uforstående overfor dit valg af en almindelig java-klasse som "facade" i web-tieren. Med facaden var det ment som en facade til business-tieren. Altså en bønne man laver lookups til ude fra web-tieren. Så skal du i din web-komponent kun holde styr på én EJB-ref.
Pt bruger jeg en almindelig klasser, men kan da godt se at der bedst at bruge en sessionBean som fasade til buisness tierne. Hmm det kommer til at betyder at jeg endnu engang ikke får søvn i nat. Ud fra de links du har givet mig at det da helt klart at det er bedre at bruge en sessionBean som en fasade. Problemt i mit tilfælde er at jeg skal konvertere mine alminde javaklasser til en sessionBean. Kama er det for meget forlang hvis jeg beder dig om at smide noget kode, kan ikke rigtig overskue at skulle sætte mig ind i et helt ny patterne pt. Hvis jeg ser noget kode er det meget nemmere for mig at overskue og bruge :-)
Skynd dig at løbe ned i din lokale GAD. Du bor i Vejle, ik'? De har med stor sandsynlighed bogen på hylden. I bogen er der mht. EJB 1.1 nogle ekstra "tricks" ifbm. Value Objects. Men det hele er forholdsvist lige ud ad landevejen.
kama har kigget på mønstret. Det ser ok ud, men jeg har et enkelt spørgsmål. Hvad er det gode ved at første kalde en SessonBean der så kalder videre til dine andre EntityBean,s. Ved at bruge en almindelig Java klasser som en fasade skal du ikke lave lookup til den som ved en sesionBean og derved undgås et lookup
Kwh - jeg har en enkelt kommentar - hvis de data du viser på dine jsp sider er readonly, er det meget tungt og performance krævende at bruge entity beans - opslag via jdbc er mindre performace krævende, og dermed hurtigere
Lad være med at bruge session beans, hvis du ikke skal bruge transaktioner. Lad være med at bruge entity beans, hvis du ikke har noget at persistere.
Derudover, Thomaz, så er det fint med en alm klasse til at cache statiske read-only data, men de kan lige så vel læses via rå JDBC. Hurtigere, lige så effektivt, og så kan klassen lægges ind i alle jsp sider som <jsp:useBean id="cache" class="CacheClass.class" scope="application" />
Jeg er helt enig med logical, det er ikke nødvendigt at bruge bønne hvis man ikke skal bruge de services en container tilbyder, bla transaktioner, persistens. Jeg arbejder selv med et sys der idag bruger mange bønner, og er ved at lave det hele om til JDBC kald hvor det kun er read-only, det er meget hurtigere. Og hvis det er data der ikke bliver ændret så ofte er det en god ide at lave en cache til at gemme data, dermed undgår du også jdbc kald i mange tilfælde, men det kommer jo an på hvor dynamiske dine data er
kristianp og logical. Er ikke enig i at entity beans kun er til persistering. Jeg har designet et system, hvor en entity bean bliver brugt til caching af read-only info fra backend via. JCA. Bruger dermed den caching-mekansime, som er inkluderet i EJB-serveren i stedet for at kode min egen.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
