Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino
Java Web Frameworks
flaite:
Spring JDBC kann man sich etwa so vorstellen. So sieht das in einer statischen Helper Klasse für meine Integrationstests aus:
->
--- Code: ---// das sql statement -> alle offers für einen bestimmten Preis und eine bestimmte Aktie
public static final String GET_OFFERS_FOR_STOCK_AND_PRICE = "select id, iduser, idstock, amount, price, creation from offerstock where idStock=? and price=?";
// gebe Liste für die Aktie und den Preis zurück
public static List<Offerstock> getOffersForStockAndPrice(final SimpleJdbcTemplate simpleJdbcTemplate, Stock stock, double price) {
// ok. Das ist eine anonyme innere Klasse, die unten aufgerufen wird (no panic)
ParameterizedRowMapper<Offerstock> mapper = new ParameterizedRowMapper<Offerstock>() {
// notice the return type with respect to Java 5 covariant return
// types
public Offerstock mapRow(ResultSet rs, int rowNum)
throws SQLException {
// für jedes einzelnen Wert des Resultsets wird ein Wert im Objekt gesetzt, das wiederum in die Liste kommt, die am Ende zurückgeliefert wird.
Offerstock stockOffer = new Offerstock();
stockOffer.setId(rs.getLong("id"));
int idUser = rs.getInt("idUser");
User offerer = findUserById(simpleJdbcTemplate, idUser);
stockOffer.setUser(offerer);
int idStock = rs.getInt("idStock");
Stock stock = findStockById(simpleJdbcTemplate, idStock);
stockOffer.setStock(stock);
stockOffer.setAmount(rs.getInt("amount"));
stockOffer.setPrice (rs.getDouble("price"));
stockOffer.setCreation(rs.getTimestamp("creation"));
return stockOffer;
}
};
// hier wird das alles aufrufsmässig zusammengeknotet.
return simpleJdbcTemplate.query(GET_OFFERS_FOR_STOCK_AND_PRICE, mapper,
new Object[] { stock.getId(), price });
}
--- Ende Code ---
Nicht so schwierig und Schema F. Spring JDBC ist eine der nicht allzu häufigen Sachen in Spring, in denen Java5 echt Vorteile bringt. Muss aber nicht.
Das ist schon die komplizierteste Methode, da es hier n:1 Beziehungen von offerstock zu user und stock gibt.
flaite:
Ich versuche am WE meine Beispielanwendung Fussi-Börse in Google Code einzuschecken. Das ist auch ein brauchbares Beispiel (find ich).
Der Vorteil mit den Schichten besteht v.a. auch darin, dass Teile der Anwendung automatisiert testbar werden.
Z.B. gibts folgende Operation:
Ein User stellt ein Kaufgebot ein.
Das System sucht nach Verkaufsgeboten, der Preis >= dem Preis des Kaufgebots ist.
Wenn solche "matchende" Kauf- und Verkaufsgebote gefunden werden, findet eine Handelstransaktion statt, d.h.:
In der Datenbank wird ein Datensatz in die Tabelle Stocktransaction eingefügt.
In der Datenbank wird dem Geld-Konto des Verkäufers der Betrag der Handelstransaktion gutgeschrieben und dem Geldkonto des Käufers abgezogen.
In der Datenbank werden dem Aktien-Konto des Verkäufers die gehandelten Aktien abgezogen und dem Aktien-Konto des Käufers gutgeschrieben.
In der Datenbank wird der Preis der Aktie auf den Preis dieser letzten Aktientransaktion gesetzt.
Alles vom Business Case aus ziemlich kompliziert und wenn man für jede Änderung den Tomcat im Debug-Mode starten müsste, durch den Code fuhrwerken müßte und gleichzeitig 6 (hab gezählt) Tabellen der Datenbank im Auge behalten, die von dieser einen Operation betroffen sind... Da wird man wahnsinnig.
ABER: Die Funktion ist als Operation einer Klasse im Service-Layer definiert. Die ist völlig unabhängig vom (Web-) Frontend. Ich hab eine Testklasse, die die Test-Datenbank auf einen von mir kontrollierten Stand bringt. Und eine Test-Methode, die die Service-Methode selbst und jede Auswirkung auf die Datenbank per Knopfdruck testen kann.
Dies gibt dem Entwicklungsprozess eine ganz neue Art der Sicherheit. Normalerweise würde man von solchen komplexen Operationen änderungsmässig die Finger lassen. Und vielleicht ist man nie ganz sicher, ob das tatsächlich wie erwartet funktioniert und ob da nicht vielleicht doch irgendwo ein kleiner bug... Mit solchen isolierten und wiederholbaren Tests ist das alles kein Problem mehr. Ich brauch nicht mal Tomcat hochzufahren.
Natürlich ist das auch eine leckende Abstraktion, weil in eine Webanwendung solche Kauf und Verkaufsoperationen multithreaded durchgeführt werden und das hat Auswirkungen auf Datenbanklocks mit z.Zt. hohen Deadlock Risiken. Aber dafür gibts auch Test-Tools (da arbeite ich noch dran). Und gegen eine Menge Bug-Möglichkeiten kann ich mit meinen aktuellen Werkzeugen per Knopfdruck aufdecken.
Aus meiner Sicht sprechen gerade diese Unterstützungen für einen zielgerichteten Entwicklungsprozess für Java/J2EE. Besonders kompliziert ist es auch nicht.
Spring unterstützt btw. immens beim einfachen Zusammenlöten einer geschichteten Architektur. Im Grunde ist der "Anfang" des Springframeworks (der dependency injection fähige Bean Container) dafür gebaut.
Gruß Axel
Mark³:
nach meinen Kurzausflügen in Spring mit ZK und Hibernate (ich habe jeweils kleine laufende Beispiele hinbekommen) frage ich mich nun wieder, ob ich nicht doch gleich meine Anwendung als LifeRay-Portlet entwickeln kann, da dort ja Spring und Hibernate schon drin ist. Es gibt auch ein oder zwei Artikel darüber, aber das ist alles sehr unübersichtlich. Schon die EXT-Entwicklungsumgebung genau so hinzubekommen, dass man den Beispielen folgen kann, ist kaum möglich.
Mein revidierter Fahrplan sieht nun erstmal so aus:
LifeRay auf MySQL umstellen (fast fertig)
meine Datenbank oder Tabellen mit Hibernate in LifeRay integrieren und ein Portlet schreiben, was darauf zugreift. Wenn das einigermassen klappt werde ich so fortfahren. O0
Mark³:
ich bin dabei, nach der Anleitung für JSF-Portlets meine Anwendung als Portlet mit Datenbankanbindung zu basteln. Hab gerade bemerkt, dass ich mit Teil e angefangen habe, die Teile davor aber als Grundlage nötig waren. Naja, klappt aber trotzdem recht gut, werde die Teile a-d nun nachholen. Man deklariert ein bisschen Kot in XMLs und LifeRay macht mit ant-Tasks dann alle DAO-Klassen und SQL-Skripte.
Mark³:
ich habe mein Portlet nun soweit funktionsfähig, dass ich mit JSF in LifeRay Datensätze in meiner MySQL-DB anlegen kann. Leider klappt die Anzeige der vorhandenen Datensätze nicht. Die gesamte Zugriffsschicht mit Hibernate generiert LifeRay selbst, beim Anlegen neuer Datensätze klappt das sehr gut. Aber beim Auflisten der vorhandenen Sätze bekomme ich eine leere Seite im Portlet. Kein Fehler, keine Überschrift mit leerem Datentable, einfach gar nichts.
Ich suche hier schon ewig rum, vergleiche das immer mit dem Beispiel 'JSF Portlet Database interaction' von LifeRay, sieht alles korrekt aus, aber klappt nicht.
Das muss doch ein gravierender Fehler sein, wenn die komplette JSF-Seite nicht angezeigt wird, es kommt aber nirgendwo eine Meldung:
--- Code: ---<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<f:view>
<h1>Display Access Models</h1>
<h:dataTable headerClass="portlet-section-header"
rowClasses="portlet-section-body,portlet-section-header-alternate"
value="#{access.getAllAccessEntries}" var="accessItem">
<h:column>
<f:facet name="header">
<h:outputText value="Access Number" />
</f:facet>
<h:outputText value="#{accessItem.accessNo}" />
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Employee ID" />
</f:facet>
<h:outputText value="#{accessItem.employeeId}" />
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Create Date" />
</f:facet>
<h:outputText value="#{accessItem.createDate}">
<f:convertDateTime type="both" dateStyle="short" timeStyle="short" />
</h:outputText>
</h:column>
</h:dataTable>
<br />
<br />
<h:form>
<h:commandButton action="back" value="Back" />
</h:form>
</f:view>
--- Ende Code ---
Ich hatte auch schon probiert, die Werte mit accessItem.access.employeeId anzusprechen (analog zu anderen Beispielen) aber beides klappt nicht und nix Fehler
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln