Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

createSession im Tomcat auf partitioned Server

<< < (4/5) > >>

Thomator:
Hi Axel,

da ist vielleicht auch ein kleines Missverständnis aufgekommen. Es ist nicht so, dass in den Methoden des Servlets (doGet, doPost) sämtliche Logiken implementiert sind.

Da hängt noch ein ziemlich umfangreiches Klassenmodell dahinter. Letztenendes werden in den Instanzen der einzelnen Module die Validierungen und Ausgaben des HTML-Codes vorgenommen und an das Response-Object weitergeleitet. Diese Instanzen greifen wiederum auf eine 'Zugriffsschicht' in Form von anderen Klassen-instanzen zu.

In den Objecten (Modulen) findet auch das Caching statt, so dass der HTML-Code nicht jedesmal neu berechnet werden muss.

Es gibt also schon einen Unterteilung in Schichten. Auch alle Interfaces sind selbst implementiert. Es wurde also eben kein existirendes Framework verwendet (weil zum Zeitpunkt des Projektstarts auch noch kein Ausgereiftes verfügbar war), sondern eine Art Framework wird praktisch in der Architektur selbst abgebildet.

Allerdings bin ich, wie schon angemerkt duraus auch der Meinung, dass hier eine bessere Kapselung möglich und sinnvoll wäre.

Die Performance-Geschichte haben wir auch schon durch. Dafür haben wir mit JMeter die entsprechende Last erzeugt, über das Logging, was Bestandteil der Anwendung ist, den Start und das Ende jeder Methode mit den Zeiten ausgeben lassen, und dann die Flaschenhälse gesucht (eingegrenzt) und auch zum großen Teil gefunden.

Das ist zwar sicher etwas umständlich, hat aber echt was gebracht.

Thomas

Nachtrag: Das Klassenmodell besteht insgesamt aus 57 Klassen und Interfaces

2.Nachtrag: Mit Servlet meine ich immer die komplette Anwendung, was wohl zu der fälschlichen Annahme geführt hat, dass alles in der Klasse, die von HTTPServlet abgeleitet ist, implementiert ist.

Thomator:

--- Zitat von: Marinero Atlántico am 28.01.05 - 11:33:24 ---P.S. ich kann da keine Tipps zu geben. OO kann man nur über Bücher und erfahrene Kollegen und eigene Erfahrung lernen. Es ist ein langwieriger Prozess. OO hat sich heute in der Programmierung weitgehend durchgesetzt. Es ist kein neues Thema.

--- Ende Zitat ---

Einen hab ich noch: Die OO ist auch für mich nix neues. Ohne kann man mit Java auch reichlich wenig anfangen. Allerdings verstehe ich nach Deinem letzten Posting Deine extrem entsetzten Antworten. Ich hab da wohl ein bisserl schwammig formuliert... ;D

Thomas

Marinero Atlántico:
So bescheuert können noch nicht mal Leute sein, die in Internet-Foren posten (bin selber einer)  ;D

Im Grunde ist ja die Anwendung dann schon irgendwie gelayered.
Wirklich hilfreich finde ich "Patterns of Enterprise Architecture" und "J2EE Patterns" von Krupi, etc.

Ansonsten bin ich ein zunehmend großer Freund von standardisierten Frameworks wie tapestry, spring und iBatis oder hibernate.
Das mit der kompletten Definition des UIs in Notes. Kenn das natürlich nicht. Aber das bringt dann natürlich irgendwie da so einen ganz eigenen Templating Mechanismus da rein und ich würde das erst einmal für bedenklich halten.
Im Grunde gibt es sowas ja schon mit JSP oder andere Techniken. Naja ist wohl in der supi-Kreativ-Zeit der dot.Com bubble entstanden, bevor die wirtschaftlichen Realitäten den Proggis gezeigt haben, wo ihr wirklicher Platz ist. Und das da nicht jeder seine eigene Duftmarke eines Templating Mechanismus schaffen sollte. Besser code von Leuten nehmen, die das auch wirklich können (framework Entwickler), diese lernen und dann die business cases der Wirtschaft erfüllen. 

57 Klassen/Interfaces bei 40.000 Zeilen code finde ich immer noch extrem wenig.


Gruß Axel

Thomator:
Hi Axel,


--- Zitat von: Marinero Atlántico am 28.01.05 - 13:52:00 ---57 Klassen/Interfaces bei 40.000 Zeilen code finde ich immer noch extrem wenig.

--- Ende Zitat ---

das ist auch der Grund, weshalb wir noch mal an die Schichtentrennung ranmüssen. Hier sind teilweise Klassen dabei, die über 3000 Zeilen Quellcode enthalten. Das ist natürlich tötlich.
Da macht sogar Eclipse schlapp (wenn ich so eine Klasse mit [STRG + UMSCH + F]  formatieren will, kommt ein Speicherüberlauf zustande ;D)

Im Rahmen dieser Umstrukturierung werde ich auch mal schauen, was man an Standard-Frameworks verwenden kann. Da mus natürlich auch der Aufwand in vernünftigen Relationen zum Nutzen stehen. Na, mal sehen...

In jedem Fall danke ich Dir für deine engagierten Beiträge. Wenn es so weit ist, weiß ich ja jetzt, dass ich hier kompetente Ansprechpartner finde.

Gruß Thomas

Marinero Atlántico:
Hi,

Du weisst, dass du mit -Xms und -Xmx der von Eclipse genutzten VM mehr Heap-Speicher spendieren kannst?
Müsste aber jetzt auch nachschlagen, wo man das einstellen kann (keine Zeit). Man kann auf jeden Fall der benutzten VM Startparameter übergeben.

eigentlich die Standards oder meine derzeitige Meinung:
Erstmal den Business Layer schreiben.
Hier ggbfls Spring einfsetzen (relativ steile Lernkurve).
Wichtiger ist aber einen Business Layer zu schreiben, der von den meisten cross cutting concerns wie Datenbankzugriff, Security, Logging, und dem Frontendlayer unabhängig ist.
Caching ist imho als cross cutting concern am stärksten mit dem Business Layer verbunden. Hier vermutlich Proxy Design Pattern (GOF).
Unit Tests schreiben. Ist gerade mit Eclipse wirklich nicht so schwierig und macht Sinn.

Für Notes Zugriff einen eigenen Object-Domino Mapper schreiben.
Für RDBMS iBatis oder Hibernate.

Für Webfrontend den Klassiker struts oder das neuere Tapestry.   

Unbedingt Fowler "Patterns of Enterprise Application Architecture" sowie "Effective Enterprise Java" von Ted Neward kaufen lassen.
 
Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete