Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Java Web Frameworks

<< < (3/7) > >>

Mark³:
Axel,

theoretisch hast du natürlich Recht und man sollte Anwendungen eigentlich nur nacheinem guten Modell entwickeln. Und natürlich ist das auch mein Ziel. Nun kommt da leider mal wieder die Realität dazwischen. Wir leben im ITIL-Zeitalter der Workarounds, hauptsache schnell und billig und es muss irgendwie laufen. Ich muss nun einen Kompromiss finden:
So schnell wie möglich und dabei trotzdem ein gutes Modell und eine gute Technik einsetzen. Wenn ich das sehr gut konzipiere und dabei eine langfristig günstigere Anwendung baue ist das schön. Wenn ich aber nach der Zeit x nicht fertig bin dann wird diese Anwendung gar nicht realisiert, daher benötige ich schnell was nutzbares was dann noch verfeinert werden kann.
Meine ersten Hibernate-Erfahrungen habe ich nun ja, ich denke ich werde daher Hibernate für die DB-Zugriffe einsetzen. Für das GUI möchte ich ZK nehmen, weil es damit extrem schnell ist, die benötigten Formulare zu bauen. GUI ist sonst nämlich sehr zeitraubend. Nun fehlt also noch eine Service-Schicht, die mir die Logik implementiert. Leider habe ich noch so kleine Randproblemchen, z.B. dass ein Teil meiner Stammdaten mittels einer DLL aus einem Fremdsystem importiert werden muss. Das geht mit vb oder LotusScript recht einfach, aber kann ich von Java aus über eine C-Schnittstelle Daten holen? Wenn das kompliziert ist werde ich die Daten über den Zwischenschritt Notes oder VB in die Datenbank schieben, da in Notes die Prozeduren schon existieren. Ein weiteres Problem sind die Berechtigungen:
In Notes hatte ich meine Leser- und Autorenfelder, und gut. Nun muss ich wohl die gesamte Berechtigungsstruktur selbst bauen.

Mark³:
ich habe mir das CaveatEmptor-Beispiel mal angeschaut (leider ohne passendes Buch). Das sieht sehr gut strukturiert aus, allerdings ist es schon ziemlich abstrakt. Nun weiß ich auf jeden Fall, warum eine Anwendung, die man in Domino in 10 Tagen fertig hat, in Java mindestens 20 Tage Aufwand bedeutet. Irgendwie fehlt mir auch noch der Zugang zur echten OOP, da ich eigentlich nie Vererbung nutze. (Habe auch noch nie umfangreichere Java-Projekte erstellt).

flaite:
Mark,

das hat nichts mit monate- oder wochenlanger Modellierung zu tun. Es geht einfach darum, sich vorhandene Beispielanwendungen in dein Eclipse zu laden und davon abschreiben.
Wenn das nicht so perfekt ist am Anfang, kannst du das immer noch refaktorieren. Eclipse behält hier einige interessante Unterstützungsfeatures bereit.

Die Servlet Spec unterstützt Authentifizierung, rollenbasierte Autorisierung und deklarative Sicherung des Transports (SSL). On Top gibts noch acegi security für Spring und J2EE Security. Eine praktische Umsetzung einer einfachen Umsetzung dieses in Tomcat findet sich auf Seite 151 ff des Arbeitsbuch Java Server Faces von Bernd Müller. Der benutzt natürlich auch eine geschichtete Architektur mit Service Layer und DAOs.

dlls können mit JNI angesprochen werden (z.B. http://dn.codegear.com/article/20679). Wenn das zeitgesteuert immer neu importiert werden soll, nimm quartz (hat super Spring Integration btw).

Ich werd das heute abend mal mit Service Layer und DAO implementieren.  Wenn du Spring benutzen würdest, wär das natürlich ein bischen einfacher. Warum benutzt du eigentlich kein Spring? Hier ist Beispielcode: http://zkoss.org/smalltalks/springdao/sdao.html

Ich benutze Unit-Tests und praxis-erprobte Architekturen, um schneller und zeitlich voraussehbarer business cases umzusetzen. Das passt prima zu ITIL. Zumindest aus meinem Verständnis. Ähnliche Pragmatismus-Debatten fanden hier vor 4 Jahren bezüglich Notes vs. J2EE oder PHP vs. J2EE statt. Ja ich weiss. Design von Java Anwendungen erfordert monatelanges obbbbjekkkkt-orrrrienttttiertes modellllierrrren. Die Kunden werden das irgendwann merken und zu "einfacheren" Lösungen zurückkommen. Genau das ist geschehen.  :D Im Enterprise Umfeld ist PHP ein großes Thema und J2EE, Spring, Hibernate und der ganze Java-Patterns Quatsch vergessen. Mit Java benötigt man doppelt so lange, weil das so abstrakt ist. Ja. Ich weiss. Die ITIL süchtigen Manager checken das einfach nicht. Und erstmal abstrakt aussehende Sachen werden nicht einfacher, wenn man sich eine Weile damit beschäftigt. Oh nein. Natürlich nicht.

Ich hab selbst die Erfahrung mit Hibernate gemacht:
Datenbankmodelle mit sehr wenig Tabellen und Beziehungen rechtfertigen kein Hibernate. Bei Datenbankmodellen mit einer Menge Tabellen und Beziehungen wirst du unweigerlich auf ein paar Dinge in Hibernate stossen, die ein profundes Verständnis von Hibernate einfordern. Du kannst ja mal dein Design auf dem Forum von Hibernate.org posten. Tipp: Nimm einen falschen Namen. Poste dann hier bitte die URL. Ich lese gerne Foren shoot-outs.

Gruß Axel

Mark³:
ZK mit Spring sieht interessant aus. Ich hatte Spring bisher aussen vor gelassen, weil ich nicht alles auf einmal lernen kann während ich hier das normale Tagesgeschäft mache  >:D
Für meine Anwendung wäre es evt. das schnellste, gar kein Framework zu nehmen, aber ich will so professionell arbeiten wie es unter den Umständen geht und auch in die Zukunft investieren. Der Small Talks-Artikel schlägt eine Lösung von ZK und Spring ohne Hibernate vor, korrekt? Meine Datenbank wird sicher nicht sehr komplex (etwa 10 Tabellen und ein paar Views) da wäre Hibernate wohl eh nicht so wichtig, oder? Oder ist es schneller, gleich Spring und Hibernate zu nehmen? Ich habe jedenfalls etwas Angst, dass ich nachher zig Frameworks nehme, die sich alle gegenseitig mit Abhängigkeiten überschlagen, so dass ich gar nicht dazu komme, meine Anwendung zu bauen. Mein Ziel ist ja immer noch, LifeRay und Alfresco als Plattform zu nehmen, aber die Plattform kann ich wohl erst nächstes Jahr nutzen. Daher will ich schnell was aufsetzen, um produktiv zu arbeiten und dabei wichtige DInge lernen, die ich später wiederverwenden kann. Ausserdem soll dann eine evt. Migration nach LifeRay einfach gehen. (Alfresco nutzt ja auch Hibernate und Spring, sollte also nicht so schlimm sein)

flaite:
Bei Spring kannst du sehr problemlos zwischen verschiedenen RDBMS Zugriffsarten wechseln.
Spring JDBC erfordert  zwar ein bischen mehr Handarbeit als Hibernate, ist aber dafür deutlich transparenter. Hibernate sieht erstmal sehr einfach aus, hat aber - wie jeder Objekt Relationale Mapper seine interessanten Geheimnisse.
(Ted Neward hat O/R-M mal mit der Perzeption von Vietnam im pol. System der USA verglichen. Für mich als kolonial/Imperialismus-geschichtlich Interessierten und Apocalypse Now Bewunderer, inklusive des zugrundeliegenden Herz der Finsternis von Joseph Conrad ein Text, den ich für bemerkenswert halte.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
)
Ich kann beides supporten.
Es ist schon richtig, dass das Zusammenspiel von Spring und Hibernate ein paar extra-Rätsel aufgibt. Es ist aber händelbar. Ich mach das. Viele machen das.
Ich würde definitiv eher auf Hibernate als auf Spring verzichten. (KORRIGIERT)
Vielleicht versuchst du mal diesen Artikel + Beispielcode. Dort ist ja der Stack Spring JDBC - ZK beschrieben (inklusive fertiger Beispielanwendung). Werd das auch mal versuchen.
 
Ich finde es übrigens eine Unverschämtheit, dass diese openSource Frameworks immer best practices in Form von laufenden Code liefern. Warum machen sie es nicht einfach wie IBM und Lotus? Ihre Lösung in Doktor-Arbeits-Form in den Himmel zu lösen. Für Beispielanwendungen gibts vielleicht Unterstützung in der Blogosphäre. Dieser abstrakte lauffähige Code verwirrt nur.  ;D

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete