Erste Gehversuche mit JSP und Servlets [Part1]

Die Vorsehung

Ich werde mich in den nächsten Tagen mit den Möglichkeiten von JSP und Servlets beschäftigen. Wichtig ist mir dabei folgendes:

• den Code möglichst übersichtlich halten
• Trennung von Applikationslogik und Darstellung (damit die Designentscheidungen die ich treffe, leicht geändert werden können)
• Die Wiederverwendung von Code, das wird wohl heißen: Code in Klassen kapseln und möglichst allgemein schreiben.

Eine Spur: Java Beans

Soweit ich gesehen habe, wird es dabei auch notwendig sein, sich mit Java Beans zu beschäftigen. Dabei geht es um Folgendes: Oft ist es…

[...]wünschenswert, mittels Introspektion und Reflection Informationen zu beteiligten Objekten ermitteln zu können. Damit dies gelingen kann, ist eine Namens-Konvention unerlässlich, um bspw. Arbeits-Methoden von Methoden unterscheiden zu können, die den Zugriff auf gekapselte Attribute ermöglichen.

Mit Namenskonvention ist scheinbar gemeint, setAttribute() und getAttribute()-Methoden immer mit der gleichen Bezeichnung zu verwenden. Das heißt set und get stehen immer vorne und danach kommt, der erste Buchstabe wird groß geschrieben, der Attributname, der entweder gelesen (get) oder geschrieben (set) wird. Also Datenkapselung mit Namenskonventionen.

Go Hardcore: Grundlegendes zu JSP/Beans

Erste Anlaufstelle ist (von dort ist auch das obige Zitat): http://www.jsptutorial.org wo die Dinge, die ich brauche (JSP, Servlets, Beans) ziemlich ausführlich beschrieben werden.

Es gibt anscheinend bestimmte Entwicklungsmodelle. Es wird von Modell1 und Modell2 gesprochen, wobei Modell 1 nur aus Servlets besteht und Modell2 dürfte eine für Web-Applikationen abgewandelte Version von MVC (Model View Controller) sein (vgl dazu: http://www.jsptutorial.org/content/architecture ).

Sprachverwirrung: MVC oder B-C-E ?

Achja, was mir noch ganz brauchbar erscheint, ist die Unterscheidung zwischen den 3 Arten von Klassen (aka: Klassen von Klassen oO), die in der UE vom Herrn Engelbrecht erwähnt wurden. Ich bin gerade auf die Suche gegangen, und habe gerade noch etwas darüber gefunden. Offiziell heißt es: das B-C-E-Prinzip

B-C-E steht für Boundary, Control und Entity und beschreibt die 3 Klassentypen die es gibt. (Natürlich gibt es verschiedene Ansätze welche Klassen es in einer SW gibt, und welche Funktionen sie haben. Doch das B-C-E Prinzip ist leicht verständlich und gut umsetzbar.) Man nennt dies auch das Model-View-Controler-Prinzip, was letztlich das selbe ist.

Quelle: http://wiki.delphigl.com/index.php/Tutorial_Softwareentwicklung2#Das_B-C-E_Prinzip

Aha, also im Prinzip MVC, hätte man ruhig auch gleich sagen können. Kurz erklärt (was ich mir in der UE mitgeschrieben habe) - den Link muss ich mir noch genau durchlesen:

• einfache Entitätsklassen: Beherbergen im Prinzip nur Attribute, die man mit getAttribut() lesen und mit setAttribut() schreiben kann.
• Boundary-Klassen: Hier gehts um Formulare, User-Interaktionen, etc.
• Controller-Klassen: Diese dürften die eigentliche Programmlogik beinhalten - Abläufe regeln.

So, das wars für heute. Mal sehen, vielleicht kann ich das nächste mal schon irgend einen Code zum Laufen bringen und auch wissen, was ich da tue.

NACHTRAG: Schau mir gerade die Folien des Unified Process an. Auf Folie 11 wird das BCE-Prinzip auch kurz erklärt (+ Darstellung der Notation dieser Analyseklassen).