Aggregering eller hvad

Det er en aggregering.


Hvis objektet ikke findes oprettes det til dig, da du kører med session scope lever dette objekt indtil brugerens session dør

Jeg mener at hvis du opretter den i en servlet, og kun bruger den i jsp siden, så er det en dependency.

pnr:
Nix
<jsp:useBean id="prisoplysningBean" scope="session" class="Faelles.Beans.PrisoplysningBean" />
Har intet med en servlet at gøre.

Det er måden man loader/instantierer en bean fra en jsp side på.
Servlets bruger man normalt slet ikke når man roder med JSP, servlets giver rodet og hård koblet kode.

Hvis du skal lave din JSP sider så de har høj indresammenhæng, vil man lade JSP siden have ansvaret for at vise noget grafisk, mens servletten bruges til at udføre nogle handlinger, og til sidst bruges beanen til at opbevare data som servletten har fundet/behandlet, så JSP siden kan tilgå dem. Det er også det mønster der medder "model view controller"

Jeg vil mene at det giver en meget mere overskuelig koden, hvor jsp siden kan vedligeholdes af folk som ikke ved noget om jsp. da jsp så kun optræder som små html ligene tags, og alt den "tunge kode" ligger i servletten

MVC pattern er normalt følgende:

Alle forms osv har en submit som kalder en bestemt servlet (controlleren) ud fra query parametere ser den hvor den skal redirecte til.

f.eks.

action="controllerservlet?action=shownews&id=547" (i en form def)

controllerservleten laver så intet andet en 'request.getParameter("action")' ud ud fra hvad den er så laver den en 'response.sendRedirect("showNews.jsp")'
showNews.jsp siden loader så nogle beans på den måde Thinge foreslår. Al databehandling foregår så i disse beans og jsp outputter bare det data der måtte være.

Skal det være rigtigt fint bruges det custom tags til denne output.

Man skal aldrig putte noget i en servlet som skal outputte HTML, fordi det giver en extremt kraftig kobling, som resulterer i at webdesignerne skal arbejde tæt sammen med udviklerne hvis designet skal ændres. Hvilket ikke er fornuftigt.

Vil det sige at lade en servlet stå for at finde data i en database, derefter ligge de fundne data i en bean, også fra servletten forwarde til jsp siden, som så henter beanen og viser de data der måtte være i den. Ikke er en holbar løsning?

Det er din tolkning af det.

Men hvorfor bruge en servlet med dens overhead, til at hente data i basen når en bean selv kan gøre det ?

Husk en servlet har overhead med hensyn til httpservletrequest og response osv.

Og det er ikke et rigtigt MVC pattern hvis du har 418 forskellige controllers. Man har normalt højest et par stykker, det eneste en controller skal gøre er at sende requests videre, ud fra parametere.

Men det Thinge spørg om har forresten intet med servlets at gøre, og hans objekt bliver instantieret/hentet via de to linier han har postet, altså en aggregering.

Jeg har samme mening, som disky, hvad angår aggregeringen. Jeg tror at pnr og jeg måske har samme opfattelse af hvad en Bean skal indeholde og gøre. Jeg mener at en Bean kun skal indeholde data, og set- og getMetoder, ellers ingen funktionalitet.
Derimod skal servlet gøre alt det "hårde arbejde" som gå i databaser osv. Man kan så diskutere om der skal være mange servlets eller ej. Det kommer vel anpå hvor forståelig servletterne skal være!

thinge:
Bare pas på med at bruge servlets de har et unødvendigt overhead.
Som du kan undgå ved at bruge almindelige klasser.

Ved at bruge almindelige klasser opnår du samtidig en genbrugelighed, nemlig det at din klasse til at hente f.eks. adresser fra en database, også fint kan anvendes i din java application, det er langt mere besværligt med servlets.

Servlets er mig bekendt ment som noget der kan outputte binær/html data til websider. At det så er dumt at bruge dem til HTML er en anden sag (hård kobling)

Tak for de gode råd disky

selv tak