Webshop Bücher

sicLotus

Bekanntes Mitglied
Hallo, sorry für den schlechten Thementitel, mir ist einfach kein besserer eingefallen.
Es geht um folgendes:
Ich möchte einen Webshop umsetzen. Demnach habe ich eine Datenbank wo Bücher und deren Genre gespeichert sind. Bei der Anzeige der Bücher, möchte ich, dass die Navigation sich quasi aufgrund der angegebenen Genre ändert. Beispiel:
Wenn in meiner Tabelle "Genre" 3 Einträge sind wie: "Horror, Fantasy und Literatur"
Dann sollen diese Punkte auch als Navigationspunkte auftauchen.

Mein Problem ist jetzt, wie ich das in JSP umsetze. Ich möchte definitiv keinen direkten Zugriff vom JSP auf die Datenbank, das wäre eine Missachtung der Projektstruktur. (JSP -> Servlet -> BO -> DAO -> DB)

Bisher habe ich das so gelöst, dass ich diese Liste der Genre in meiner Session speichere, gibt es noch einen anderen oder besseren Weg? Ich bin mir nicht sicher ob die Session genau für sowas da ist, oder wieviel man in eine Session überhaupt reinspeichern sollte. Die Frage wäre, was passiert wenn die Session abläuft? Kann sie überhaupt ablaufen?! Drückt man F5 würde ja eine neue Session angelegt werden mit der Genrelist..was sagt ihr?
 
Zuletzt bearbeitet von einem Moderator:
G

Gelöschtes Mitglied 5909

Gast
Wenn in meiner Tabelle "Genre" 3 Einträge sind wie: "Horror, Fantasy und Literatur"
Dann sollen diese Punkte auch als Navigationspunkte auftauchen.

Abgesehen davon hab ich ehrlich gesagt nicht viel verstanden. Wenn die Navigationspunkte
auftauchen sollen, machst du eine query und zeigst das ergebnis in der navigation an. Wo ist das Problem?

Du schreibst noch irgendwas von Session, das gehört definitiv nicht da rein
 

sicLotus

Bekanntes Mitglied
Ne Query kann ich ebend nicht einfach schreiben, weil das halt gegen die Webarchitektur verstößt, siehe Schichtenarchitektur(n-Layer architecture). Darum hab ich das halt inner Session gespeichert um an die Daten dauerhaft ranzukommen und nicht nur durch nen request.
 

JanHH

Top Contributor
Nicht ganz klar ob das global gilt mit dieser Genre-Liste oder von User zu User unterschiedlich ist. Wenns global ist, kann mans im Application-Scope des Servlet-Kontextes speichern, ansonsten in der Tat in der Session. Soweit ok. Aber Du kannst auch direkt auf die Datenbank zugreifen, ohne die Projektstruktur zu verletzen..

JSP fragt Servlet nach der Liste, Servlet fragt BO nach der Liste, BO fragt DAO nach der Liste..

Aber bist Du sicher dass es nicht eh mehr Sinn machen würde, das Ganze mit etwas moderneren Technologien (JSF 2.0 etc) zu machen? Kommt mir irgendwie einfacher vor.

Und was, wenn Du die Liste "dauerhaft vorhältst", aber sie sich dann doch in der Datenbank ändert? Davon würde die Anwendung dann nix mitbekommen.
 

sicLotus

Bekanntes Mitglied
JSP fragt Servlet nach der Liste, Servlet fragt BO nach der Liste, BO fragt DAO nach der Liste..

Genau so funktioniert das ja auch fast immer, aber dann würde ich ja für jeden neuen Webseiten aufruf diese Abfrage stellen. Wäre meiner Meinung nach nicht nötig, da die Genreliste gleich bleibt, sollte sie geändert werden, kann der geänderte Wert ja erneut in die Session geschrieben werden und damit wäre auch die Veränderung beachtet.

Ich mache das Projekt für die Uni, habe also nicht zuu viele freigaben was die Technologie betrifft, von daher bin ich etwas gezwungen das so zu machen. Application-Scope hört sich interessant an, da werde ich mal googlen :)
 
G

Gelöschtes Mitglied 5909

Gast
Du hast das vollkommen falsch verstanden. Du sollst das Query nicht im JSP machen. Im übrigen sollte das JSP auch nicht das Servlet fragen. Das Servlet wird aufgerufen und lässt dann das DAO das query ausführen. Dann packt das Servlet die Daten in den Request Scope und leitet (dispatched) den request an die JSP weiter. Die JSP stellt nur die Daten dar, mehr nicht. In die JSP mehr logik zu verpacken ist genau gegen die Architektur die du Anstrebst. Und wenn du so toll auf deine Architektur achtest, dann schau dir mal eine Zeitgemäße Architektur an: JSF 2, Apache Wicket, ..., denn JSPs sind veraltet.
 

JanHH

Top Contributor
Also so schlimm wär das nicht, pro dargestellter Webseite einmal kurz die Liste in der Datenbank nachschauen.

Ansonsten durchaus die Liste in die Session schreiben, dann kriegt jeder User, wenn er die Anwendung betritt (wo dann die Session erzeugt wird) die aktuelle Liste.
 
Zuletzt bearbeitet:
G

Gelöschtes Mitglied 5909

Gast
Und ob das schlimm wäre, dann würde der User veraltete Daten haben. Mitunter stark veraltete. Und das gehört nicht in die Session!
 

JanHH

Top Contributor
Häh?

Wenn man bei jeder Seite die Liste aus der Datenbank holt, ist sie immer up to date.

Wenn man die Liste in der Session speichert, ist sie ggf. nicht immer aktuell, aber man hat weniger Datenbankzugriffe.

Was davon zu bevorzugen ist, hängt vom Anwendungsfall ab, würde ich sagen.
 
G

Gelöschtes Mitglied 5909

Gast
Dafür gib es caches und die Session ist dafür schlicht und einfach der falsche Ort.
 

sicLotus

Bekanntes Mitglied
Dafür gib es caches und die Session ist dafür schlicht und einfach der falsche Ort.
Hae? Also wenn etwas veraltet ist, dann sind es ja wohl eher die caches oO?

Dein Ansatz würde aber beinhalten, dass ich IMMER ein Servlet aufrufen muss, obwohl ich vllt einfach nur ganz simple zwischen zwei JSP - Seiten linken möchte. Dann müsste ich das umständlicherweise also über einen Controller abwickeln, der null Funktionen hat, abgesehn von der DAO anfrage für die Navigation. Das entfällt aber wenn ich die Daten in der Session vorhalte..

Mir war schon klar, dass die Session dafür nicht der richtige Ort ist, deswegen habe ich ja nach einem anderen Ort gefragt ;-)
Wenn man von JSP - JSP verlinken will, dann hab ich halt kein Zugriff auf meine Dao's geschweigedenn die Möglichkeit etwas ins request zu schreiben.

Und wie ich schon sagte, ich nutze JSP nicht, weils toll ist, sondern weil ich dazu mehr oder weniger genötigt werde.
 
G

Gelöschtes Mitglied 5909

Gast
Hae? Also wenn etwas veraltet ist, dann sind es ja wohl eher die caches oO?

Bitte was? Es ging darum Caches zu verwenden, wenn es performance Seitig probleme gibt.
Es ging nicht darum alles in caches zu stecken und nur die caches zu verwenden.

Stichwort EHCache im zusammenspiel mit JPA

Dein Ansatz würde aber beinhalten, dass ich IMMER ein Servlet aufrufen muss, obwohl ich vllt einfach nur ganz simple zwischen zwei JSP - Seiten linken möchte.

Sowas nennt man dann Dispatcher (-Servlet)

Dann müsste ich das umständlicherweise also über einen Controller abwickeln, der null Funktionen hat, abgesehn von der DAO anfrage für die Navigation. Das entfällt aber wenn ich die Daten in der Session vorhalte..
Korrekt, ein Servlet ist ein Controller. Das ganze nennt man dann auch MVC.
 

fastjack

Top Contributor
Du kannst in deinem Servlet oder DAO cachen, du kannst auch die Session "mißbrauchen", oder im HTML Dokument cachen (per Javascript etc.). Das Problem ist nur, wie Du diese Caches aktuell hälst.

JSP ist schon veraltet, aber im Grunde genommen landet alles bei JSP/Servlets, auch neue Techniken. Deine JSP Seite wird eh zum Servlet ;)
 

JanHH

Top Contributor
Also eine Liste mit irgendwelchen Dingen zu Beginn einer HTTP-Session aus der Datenbank zu lesen und aus Performancegründen in selbiger zu speichern, um nicht für jede dargestellte Webseite wieder auf die Datenbank zugreifen zu müssen, ist definitiv völlig in Ordnung, was den Entwurf angeht, nicht veraltet, und eigentlich DAS Standardverfahren, um sowas zu machen. Das einzige was man sich da fragen muss ist, ob es ein Problem ist, dass ein User in seiner Session eine veraltete Liste hat, wenn diese sich in der Datenbank in der Zwischenzeit ändert. Hängt halt von der Art der Anwendung ab. Bei einem Buch-Webshop dürfte es nicht so problematisch sein. Also, nur zu..
 

vladimir75

Bekanntes Mitglied
Das einzige was man sich da fragen muss ist, ob es ein Problem ist, dass ein User in seiner Session eine veraltete Liste hat, wenn diese sich in der Datenbank in der Zwischenzeit ändert. Hängt halt von der Art der Anwendung ab. Bei einem Buch-Webshop dürfte es nicht so problematisch sein.

Jeder der mit Regulären-Büchern handelt (nicht Mängelexemplare, Ladenpreisaufgehobene Büchern) bekommt von Lieferanten z.B Libri Listen mit Büchern die aus rechtlichen Gründen nicht mehr zum Verkauf angeboten dürfen. Bis zu 3-4 Titeln pro Woche. Wer zu spät solche Titeln aus der DB raus filtert, darf bis zu 1000 EUR Mahngebühr zahlen.

Stellen wir vor, in deinem Shop sind 1000 Kunden oder auch die Suchmaschinen gleichzeitig unterwegs. Jeder bekommt eine eigene Session. Die Sessions, in denen das Navigationsmenü weiter von Seite zu seite geleitet wird. Änderst du was in der DB, musst du alle Sessions neu schreiben. Ist das richtig? Wenn jeder User eigene, unterschiedliche Menüleiste bekommt, dann verstehe ich das. Wäre es nicht besser, solche gleichbleibende Sachen wie Navigationsmenus in Cache zu verbergen?

Entweder auf jeder Seite neue DB-Abfrage oder in Cache speichern.

Vielleicht helfen dir (oder uns) weitere Beispiele:

The Example JSP Pages
Shopping CartJSPJava
Simple Cart Java Shopping Cart / Shopcart Software
Free Java Shopping Cart,Shopping cart Application
http://www.jadasite.com/jada/web/fe/jadasite/English/content/Download+JadaSite
Session Based Shopping Cart | JSP & Servlets | Java Programming
The Example JSP Pages - The Java EE 5 Tutorial
JavaBeans Components in JSP Pages
Community Edition KonaKart – Enterprise Java eCommerce Shopping Cart Software
Apache OFBiz, The Apache Open For Business Project - Open Source E-Business / E-Commerce, ERP, CRM, POS, SCM, MRP, CMMS/EAM

Vladimir
 

F.S.WhiTeY

Bekanntes Mitglied
Also eine Liste mit irgendwelchen Dingen zu Beginn einer HTTP-Session aus der Datenbank zu lesen und aus Performancegründen in selbiger zu speichern, um nicht für jede dargestellte Webseite wieder auf die Datenbank zugreifen zu müssen, ist definitiv völlig in Ordnung, was den Entwurf angeht, nicht veraltet, und eigentlich DAS Standardverfahren, um sowas zu machen. Das einzige was man sich da fragen muss ist, ob es ein Problem ist, dass ein User in seiner Session eine veraltete Liste hat, wenn diese sich in der Datenbank in der Zwischenzeit ändert. Hängt halt von der Art der Anwendung ab. Bei einem Buch-Webshop dürfte es nicht so problematisch sein. Also, nur zu..

Ich stimme dem völlig zu und würde da auch auf JPA mit einer @Stateless Annotierten Bean rangehen. Pro Session, eine JPA-Anfrage auf den "Katalog" und in der Selbigen Speichern.
 
M

maki

Gast
Ich würde sowas nicht in der HttpSession speichern, gute JPA Provider cachen sowieso schon sehr viel und ich muss in der GUI nicht mehr Fachlichkeit nachprogrammieren, die in der BusinessTier besser aufgehoben wären.
 

F.S.WhiTeY

Bekanntes Mitglied
Es muss ja nicht unbedingt direkt in der HttpSession gespeichert werden. Kann ja auch in ner Bean mit SessionScope aufgehoben werden. Dann bleibt es in der BusinessLogik, erfüllt aber dennoch seinen zweck.
 
M

maki

Gast
Es muss ja nicht unbedingt direkt in der HttpSession gespeichert werden. Kann ja auch in ner Bean mit SessionScope aufgehoben werden. Dann bleibt es im der BusinessLogik, erfüllt aber dennoch seinen zweck.
SessionScope führt dazu dass die HttpSession genutzt wird, ist also nix anderes.

Schon klar, wenn die Daten recht "statisch" sind und sich während der Session normalerweise kaum was ändert, könnte man das schon machen, ist imho aber eher ein Ausnahmefall.

Auf der anderen Seite sind dicke, fette Sessions mit großen, langlebigen Objekten nicht gerade Clusterfreundlich bzw. gut Skalierbar ;)
 

JanHH

Top Contributor
Kommt mir irgendwie vor wie eine haaraspalterische Debatte über einen absoluten 08/15-Anwendungsfall..

@vladimir.. Du sagst ja auch nix anderes als "es hängt vom Anwendungsfall ab" ;-)
 
M

maki

Gast
Kommt mir irgendwie vor wie eine haaraspalterische Debatte über einen absoluten 08/15-Anwendungsfall..
Dann solltest du nochmals lesen, da wurden Pro & Contra Argumente für Session als Ablage gebracht.

Solche Daten in der Session abzulegen ist absolut nicht 08/15, sondern eine von mehreren Möglichkeiten und die haben eben alle ihre Konsequenzen.

Wenn man das nur lapidar mit "völlig in Ordnung" kommentiert sollte man sich vielleicht Gedanken machen ob man das nicht zu oberflächlich betrachtet, es "Standardverfahren" zu nennen ist schlicht falsch, denn die JEE Specs. definieren ein System, das Scalierbar sein sollte, das hat man eben nciht wenn man alles in die Session wirft.
 

sicLotus

Bekanntes Mitglied
Ich verstehe gerade den Unterschied nicht. Wenn ich 1000 User habe und für die, die Session neu geschrieben werden muss, dann muss ich doch auf für die 1000 Datenbankanfragen stellen?! Nimmt sich ja irgendwie nicht viel?!

Das Problem ist halt, ich kann die Genreliste mit der Webseite per JSP/Servlet jederzeit erweitern und dann wäre es schön, wenn sich meine Navigationsliste auch erweitert.. Ich hab jetzt immernoch nicht verstanden was nun am besten wäre. Ich denke das DB anfragen aufwendiger sind als Sessionanfragen?
 

F.S.WhiTeY

Bekanntes Mitglied
Ich hab jetzt immernoch nicht verstanden was nun am besten wäre. Ich denke das DB anfragen aufwendiger sind als Sessionanfragen?

Ja sind sie ABER eine DB-Strucktur lässt sich leichter und performanter Clustern als die Sessions. Wenn auf deine Seite nur 50-100 Besucher/Tag kommen ist es egal. Aber bei z.B. Amazon oder ebay ist es das nicht mehr.
 

JanHH

Top Contributor
Hm.

User startet Webanwendung -> HTTP-Session wird erzeugt.

Variante A: Genreliste wird dann aus DB gelesen und in der Session des Users gespeichert. Hat zur Folge dass die Liste, die der User sieht, sich nicht ändert, wenn während der Laufzeit der Session die Liste in der Datenbank geändert wird.

Variante B: Liste wird bei jedem Seitenaufbau aus der Datenbank geholt. Hat mehr Datenbankzugriffe zur Folge, aber die Liste ist immer aktuell.

Was davon zu bevorzugen ist, hängt, wie schon gesagt, vom Anwendungsfall ab.

Aber da die Datenbanksysteme eh leistungsfähige caching-Mechanismen haben, macht es wenig Sinn, diese nicht zu nutzen, sondern statt dessen einen eigenen (was das Speichern in der Session ja im Grunde ist) zu bauen. Also ich denke nicht, dass das die Performance spürbar bremst.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
S JSP Webshop mit JSP Web Tier 2
M JSF Webshop Web Tier 9

Ähnliche Java Themen

Neue Themen


Oben