Frage

Ich bin ein großer Fan von in der Servlet-Anwendungslogik zu halten, und die JSP so einfach wie möglich zu halten. Einer der Gründe dafür ist, dass jede gute Web-Designer in der Lage sein sollten, auf seine HTML-Kenntnisse zu erweitern in wenigen JSTL-Tags zu bauen einfache Iteration zu tun, Zugang Bohnen, etc. Wir halten auch die komplexeren / Ajax / js Komponenten hinter eine Tag-Bibliothek (ähnlich displayTag aber für eigene Komponenten).

Die meiste Zeit funktioniert alles ok aus - Das Servlet hat jede SQL es braucht, und speichert die Ergebnisse in Bohnen für die JSP-Zugang. Wo wir haben ein Problem, wenn die Datensätze wir zugreifen möchten durch das Design festgelegt.

Das deutlichste Beispiel ist die Homepage - es braucht Blickfang und wirksam zu sein. Es braucht nicht wie Rest der Website einheitlich zu sein. Es gibt viele Einzelanfertigungen oder „Sonderfälle“ hier, wo wir ein bestimmtes Produkt Datensatz abfragen wollen, oder was auch immer.

Was die Designer wirklich will, ist eine Möglichkeit, ein Produkt Bohne durch die Produkt-ID zu bekommen, damit er die Eigenschaften als normal zugreifen kann. Wir wollen natürlich nicht für alle Produkte abfragen, und ich möchte nicht in der Präsentation abzufragen.

Ich bin mir ziemlich sicher, dass ich das Unmögliche hier bin gefragt und ich habe etwas zu verzichten. Meine Frage ist, was?

Bearbeiten

Bin ich falsch in der Annahme, dass alle Anwendungslogik vollständig sein sollte vor Aufruf der JSP? Ich hatte den Eindruck, es am beste Praxis betrachtet wurde dann in dem Servlet all Abfrage- / Berechnung / Verarbeitung zu tun passieren (ziemlich) stumm Bohnen auf einen (sehr) stumm JSP.

Es gibt ein paar Methoden, wobei die tatsächliche Komplexität der Abfrage kann in einer anderen Klasse (benutzerdefinierter Tag oder Bohne) eingekapselt wird, und die JSP kann es nennen. Diese hält die JSP einfach (Ziel 1), aber die JSP noch „Auslösung“ die Abfrage - ganz spät in den Prozess einzubeziehen.

  • Habe ich diese völlig falsch und es ist in Ordnung, dies zu tun.
  • Ist es eine allgemeine Regel, aber vollkommen in Ordnung, dies in diesem Fall zu tun ist.
  • Kann ich auf Probleme stoßen?

EDIT - Beispiel

Ich hoffe, dieses Beispiel helfen:

Die Homepage ist keine „Vorlage“, wie die Kategorie / Suchseiten - es kundenspezifische ist sehr gut für die Arbeit mit einem Marketing-Bild sagen und ein paar spezifischer Produktbilder. Es hat jedoch Informationen über diese beiden Produkte, die dynamisch erhalten werden sollte (so der Name, und vor allem Preis) bleiben synchron mit dem db.

Das Servlet kann nicht wissen, welche Produkte diese werden, denn wenn der Designer, sie ändern will / entfernen sie / hinzufügen mehr, sollte er nur die JSP bearbeiten müssen (und möglicherweise XML als eine Antwort vorgeschlagen).

War es hilfreich?

Lösung

Wenn ich richtig verstehe, haben Sie Logik in der JSP, die ein bestimmtes Produkt will, aber an diesem Punkt Sie wollen nicht von der DB abzufragen, und es zu spät für das Servlet sich dessen bewusst zu sein.

(Seite beachten, während ich deinen Willen respektieren Trennung von Bedenken aufrecht zu erhalten, die Tatsache, dass dies ein Problem ist eindeutig zeigt, dass Ihr Rahmen in der Präsentationsebene zu viel Logik hat ... aber da wir wahrscheinlich nicht beheben dass ... moving on).

Meine Empfehlung ist, dass Ihre Designer eine XML-Konfigurationsdatei erstellt, die unabhängig von speziellen Fällen enthält es für das Frontend benötigt, und Ihr Servlet, das lesen kann, dann stumm Bohnen zurück in die JSP übergeben.

oder ... Sie die Dinge nach unten in mehrere Anfragen brechen XMLHTTPRequest mit und zurück an das Servlet für jede einzelne Abfrage, dann montieren Sie die Seite auf dem Client aufrufen.

Andere Tipps

Es klingt wie Sie eine bessere Trennung zwischen dem Display und Datenbank-Code benötigen. Sie sollten separate Klassen haben, die nur mit der Interaktion mit der Datenbank umgehen und wissen nichts über Display.

Dann erstellen Sie einfach eine Methode, die das Produkt von id und zurück die Bohne aussehen wird, so kann die Anzeige der Attribute herausziehen es will.

Sie müssen eine benutzerdefinierte Bean erstellen, die Ihre Anfragen für das Frontend durchführen wird. Eigentlich ist es wahrscheinlich eher wie ein paar Bohnen, die Daten für Sie zu erhalten, je nachdem, was Sie hier sagen.

Es gibt kein Problem mit, dass aus einer Design-Perspektive zu tun; es ist nur, dass die spezifische Gestaltung der Homepage mehr heterogenen Anforderungen als der Rest Ihrer Website hat. Stellen Sie sicher, dass Ihr Designer weiß, dass er seine Bedürfnisse kommunizieren muss gut an das Entwicklungsteam die BO für Ihre Homepage erstellen (oder was auch immer) und was sollte gehen in Ordnung.

Sie sind nicht falsch in der Annahme, dass alle Anwendungslogik abgeschlossen sein sollte, bevor die JSP-Rendering.

Wenn es eine Notwendigkeit mehr Material ist für die Anzeige in Ihrer JSP zu holen, wäre es eine weitere Anforderung an den Server und einen anderen Seite Zyklus sein. Wenn Sie für ‚interaktives‘ Laden Erlebnis suchen, könnten Sie AJAX verwenden.

In einer einzigen Seite Lebenszyklus, ich finde es schwer zu verstehen, warum müssen Sie aufrufen Datenbank aus einer JSP aufruft. Hat nicht die Seite zuvor mit allen erforderlichen Formularvariablen geschrieben, Ihnen zu helfen, die Daten in Servlet / Helper-Klassen zu finden?

Wenn Sie ein Beispiel für einen Fall geben könnten, wäre es hilfreich sein.

[Bearbeiten] in Ihrem Beispiel Sehen, ja Ihre Designer (oder der Administrator der Website), die Informationen als eine Konfiguration gesetzt sollen, nicht einen Teil der JSP. Oder könnten Sie eine kleine app / Admin-Seite haben die Informationen in einer Datenbank zu halten, so dass sie auf dem Sprung geändert werden könnten. Wenn Sie Ihre Homepage zeigen, die configs lesen und die entsprechenden Daten geladen werden.

Ich bin nicht sicher, was die Frage ist. Ich f Sie SQL-Anweisungen aus Ihren jsp Seiten haben wollen, dann können Sie dies in einer Eigenschaftendatei setzen und nur die Eigenschaft Datei aus der jsp Seite lesen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top