nicht angemeldet
Moin nochmals,
Trennung von Design und Code habe ich mit einem Template-Modul geschaffen. Funkitoniert eigentlich ganz gut, aber vielleicht kann das Java auch noch besser, k.A.
Das Prinzip ist IMHO ungefaehr das gleiche, aber es gibt ja noch Code hinter der Template Engine, der noch entwickelt werden muss. Und damit bleibt die Frage, wie strukturiere ich Code (auch den von der Template Engine selbst), um den moeglichst ueberschaubar und wartbar zu machen.
Aber was ist wenn ich eines Tages dann doch auf einen Applikationsserver umsteigen wollte, kann ich dann alten Code weiterverwende, oder muss ich dann alles neu schreiben? Denn Sachen die später EJBs erledigen werde ich vermutlich vorher mit Sevlets implementieren, oder?
Ja. Vermutlich und wahrscheinlich noch diverse Hilfsklassen usw. Den dann wiederzuverwenden, wenn die Anwendung auf EJBs portiert wird, ist wahrscheinlich mehr Arbeit, als den Code neu zu schreiben. Ausserdem ist mit wiederverwendbaren Komponenten auch nicht unbedingt die erneute Verwendung des Codes gemeint, sondern eher die Wiederverwendbarkeit von Objekten, d.h. du baust z.B. einmal ein deiner Anwendung eine EJB zur Verwaltung von Adressdaten und die nimmst du auch dann, wenn du 1000.000 Adressen hast. Die Bean selber ist dann ganz anders aufgebaut, als du das z.B. in einem Servlet machen wuerdest, dass mit einer Datenbank interagiert. Die einzelne Bean stellt vielmehr (jedenfalls bei Entity Beans) einen Datensatz dar. D.h. du arbeitest gar nicht mehr direkt mit der Datenbank sondern operierst nur noch auf den EJBs, die aehnlich wie Tabellen miteinander in den unterschiedlichsten Relationen verknuepft werden koennen 1:1, 1:n usw.
Wobei man ja auch da das Problem hat was wenn ich DB-Transaktionen verwenden will, aber die DB das nicht kann, also muss ich auch an solche Dinge denken wenn ich Programmiere(nur so als dummes Beispiel, Transaktionen sind natürlich Grundvoraussetzungen).
Transaktionen, referentielle Integritaet usw. wird komplett von EJB implementiert. D.h. du kannst auch eine DB nehmen, die das nicht beherrscht, weil diese Zustaende vom Container ueber deine Beans ueberwacht werden.
also ein kompletter Request ist eine Transaktion oder sowas, aber das habe ich nicht verstanden wie das genau gemeint ist. Sowas geht dann aber nicht mit Struts oder sowas, oder?
Nee. Das Prinzip ist wie gesagt ein ganz anderes. Struts erlaubt eine sehr saubere Trennung von Model (deine Daten), View (z.B. eine jsp Seite) und Controler (der Teil, der deine Anwendung z.B. beim Absenden durch Betaetigung eines Buttons kontolliert). Bei EJBs geht es kurz gesagt darum, wiederverwendbare Komponenten zu entwickeln, bei denen du dich um ganz viele Probleme die du sonst hast, z.B. Resourcenverwaltung usw., nicht kuemmern musst. Das macht alles der Applikationserver. Der Preis den du zahlst ist der hohe Entwicklungsaufwand.
Das schon, aber auf der anderen Seite habe ich schon zu spüren bekommen dass gerade nach der New-Econemy Kriese ungern auf solche Techniken gesetzt wird, Geld spielt nicht immer eine so große Rolle, eher im Gegenteil, viele Leute haben z.B. eine tiefe Abneigung gegen PHP und MySQL, "das kann ja nichts sein...",
Ja. Das ist in der Tat ein Problem. Es wird sich aber IMHO aendern, da der Kostendruck fuer die Unternehmen immer hoeher wird. Wenn die dann eine Enterprise Anwendung wollen, bzw. brauchen, stehst du mit Open Source konkurrenzlos da. Das JBoss fei verwendbar ist, muss man ja erstmal nicht an die grosse Glocke haengen.
die Verwendung von Tomcat und PostgreSQL denn so viel besser? Im Prinzip ist es ja nur der Austausch der Sprache, aber die Architektur wird dadurch ja nicht _so_ viel "professioneller".
Genau das glaube ich eben doch. Es gibt natuerlich auch bei PHP saubere Open Source Sachen. Aber vergleiche mal irgendwelche komplexen Open Source Shop Systeme und ein Tool wie Eclipse. Bei den Shop Systemen hatte ich Anpassungen, die ein absoluter Albtraum waren. Teilweise Objektorientiert, teilweise nicht, Spaghetti Code ohne Ende, staendig wechselnde Variablennamen usw. Wobei man natuerlich der Gerechtigkeit halber sagen muss, dass hinter Eclipse zum einen auch viel mehr Geld steht, weil Firmen wie Sun und IBM dahinterhaengen. Und zum anderen wird das natuerlich von diesen Firmen gepusht, um die Vorherrschaft von Java gegen C#, bzw. die ganzen .net Geschichten durchzusetzen. Ganz andere und viel, viel maechtiger Interessen also, als dies z.B. bei PHP der Fall ist. Rechts hast du IMHO aber auf jeden Fall damit, dass PHP und MySQl nicht so ernst genommen werden. Und deshalb warens auch bei mir, zumindest teilweise, auch ganz profane wirtschaftliche Ueberlegungen, die zum Umstieg auf Java gefuehrt haben.
Ich glaube Dir auch gerne das sich Java hier viel besser eignet, nur will ich nicht denselben Fehler ein 2. mal machen, wenn man später auf einen richtigen Applikations-Server wechseln könnte wäre das ja schon nicht schlecht, aber alles ein 3. mal neu zu schreiben wäre großer Mist.
Ich wuerde mir einfach vorher ueberlegen, wie gross meine Anwendung, bzw. die Last maximal wird. Wenns maximal um ein paar tausend Datensaetze geht und die Zugriffe im Rahmen sind, tuts eine Anwendung ohne EJBs. Wenn die Last eher in Richtung des Auskunftssystems der Deutschen Bahn geht oder eines Shops wie Amazon oder Karstadt oder sowas, wuerde ich eine Enterprise Loesung bevorzugen. Vielleicht lohnt es sich aber auch schon, wenns "nur" hundert oder zweihundert User sind, die gleichzeitig die Applikation nutzen. Das kann ich nicht genau beurteilen und die Experten sind sich AFAIK auch nicht einig, ab wann der Aufwand gerechtfertigt ist.
Was ist denn wenn man JBoss mit Tomcat verwendet, und erstmal nur weitgehend mit Sevlets und wenn möglich mit wenigen vorhandenen EJBs arbeitet, wäre das nicht eine gute Möglichkeit?
Ja klar. Kann man machen. Ist wahrscheinlich allein schon zu Uebungszwecken keine schlechte Loesung, wenn du die Zeit hast, das zu machen (oder es sich vielleicht, zumindest teilweise, sogar auf den Kunden umlegen laesst).
Tomcat kann man ja wahlweise als HTTP-Server für den JBoss verwenden. Oder was hätte das denn konkret für Nachteile wenn ich direkt auf so eine Architektur schwenke? Meinst Du die Komplexität die das mit sich bringt? Ich will einen Applikations-Server weniger wegen seiner Performance-Vorteile, Skalierbarkeit..., sondern eher um eine saubere, qualitativ hochwertige Applikation hinzubekommen,
Wirkliche Nachteile hat das gar nicht. Es ist eben nur aufwendig und verhaeltnismaessig kompliziert.
Gruss
Ralf