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

Warum Java diese komischen Frameworks so beliebt sind

(1/3) > >>

flaite:
habs jetzt für meine Schulung gezeigt.

I. klassisches JDBC

--- Code: --- private List<Stockdescr> allStockdescr() {
List<Stockdescr> res = new ArrayList<Stockdescr>();
Statement stmt;
String strStmt = "SELECT * FROM STOCK_DESCR";
try {
stmt = con.createStatement();

ResultSet rs = stmt.executeQuery(strStmt);
while (rs.next()) {
Stockdescr stockdescr = new Stockdescr();
stockdescr.setId(rs.getInt("id"));
stockdescr.setName(rs.getString("name"));
stockdescr.setPrice(rs.getBigDecimal("price"));
res.add(stockdescr);
}
} catch (SQLException e) {

// TODO Auto-generated catch block
logger.error("Problems with statement: " + strStmt, e);
closeCon();
}
return res;

}

und

private void connect() {
Properties props = loadProperties("jdbc.properties");
try {
Class.forName(props.getProperty("db.driverClass"));
} catch (ClassNotFoundException e) {
logger.error("Driver not found", e);
}

try {
con = DriverManager.getConnection(props.getProperty("db.jdbcUrl"),
props.getProperty("db.user"), props.getProperty("db.pwd"));
} catch (SQLException e) {
// TODO Auto-generated catch block
logger.error("No Connection", e);
System.exit(0);
}

}

und

private void closeCon() {
if (con!= null) {
try {
con.close();
} catch (SQLException e) {
// EINER DER W.E.N.I.G.E.N FÄLLE, in denen ein leerer Exception block ok ist!!!!!

}
}
}


--- Ende Code ---

Zum Vergleich
und jetzt mit ibatis in spring für quasi das gleiche (alle Werte der STOCK_DESCR Tabelle laden).

--- Code: --- public List<Stockposition> loadAll() {
return getSqlMapClientTemplate().queryForList("allStockposition");
}

--- Ende Code ---

gut. man muss ein paar xml-config Dateien schreiben, wo unter anderem der sql code ausgelagert ist und damit auch besser separiert ist. Das ist sehr copy und paste und für neue SQL Statements gegen die gleiche Tabelle muss man nur 1 neues xml Element schreiben, für eine weitere Tabelle genau 1 weiteres xml Element.


--- Code: ---ibatis:
<sql id="select-stockdescr">
select
ID,
NAME,
PRICE
from STOCK_DESCR
</sql>

<select id="allStockdescr" resultClass="stockdescr">
<include refid="select-stockdescr"/>
ORDER BY ID
</select>


spring:
<bean id="stockdescrDao"
class="de.spintegration.fussi.dao.ibatis.StockdescrDaoImpl">
<property name="sqlMapClient" ref="sqlMapClient" />
</bean>

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${db.driverClass}"/>
<property name="url" value="${db.jdbcUrl}"/>
<property name="username" value="${db.user}"/>
<property name="password" value="${db.pwd}"/>
</bean>

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:jdbc.properties"/>
</bean>

<bean id="sqlMapClientTemplate"
class="org.springframework.orm.ibatis.SqlMapClientTemplate">
<property name="sqlMapClient" ref="sqlMapClient" />
</bean>

<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" value="sql-map-config.xml"/>
</bean>


--- Ende Code ---

Aber das ist es fast schon. Und das ist nur ein Teilaspekt der Vorteile.

 ;D

MadMetzger:
Mittlerweile bin ich nach einigen ersten Erfahrungen mit Hibernate, solchen Tools gegenüber etwas skeptisch eingestellt. Richtig ist zumindest, dass man relativ schnell eine Persistenz hinbekommt, die Daten einfach abspeichern und laden kann. Nur wird es recht anstrengend, wenn man mit historisierten und versionierten Daten umgehen möchte. Das geht dann nicht mehr mit Hibernate ohne es stark zu  verbiegen bzw. ihm was vorzugaukeln.

flaite:
Mit ibatis sqlmaps bist du SQL mässig flexibler als mit Hibernate. Es ist auch transparenter als Hibernate. Da dies auch für einen Kurs hier ist, hab ich das genommen. Und das ist lediglich ein Mapping von Beans auf SQL-Statements, kein volles OR-Mapping Tool.
Ich neige aber auch zu der Annahme, dass Hibernate ziemlich komplex ist und es dort viele Möglichkeiten gibt, bestimmte Anforderungen doch abzudecken. Du brauchst auch nicht in jeder Anwendung stark historisierte oder versionierte Daten. Eben jedes Tool für seine Aufgabe.
Ich würd immer versuchen Frameworks zu benutzen.
Wirklich große Dramen habe ich gesehen, als Leute freudig strahlend meinten, dass für ihre Anforderungen Frameworks nicht ausreichen und sie es einfacher selbst machen können. Schliesslich können sie programmieren. Da hab ich immer sehr starke Zweifel. Wenn ich an eins glaube, dann die Tatsache, dass der menschliche Geist sich sehr schwer tut mit dem Phänomen, dass die Kosten von Komplexität in recht vielen Situation exponentiell steigen können. Deshalb erzeugen die Freunde der "Einfachheit", i.S. v. ohne Framework etc, oft die größte Komplexität. Und das ist jetzt Real Life Erfahrung. Ich hab solche Systeme schon maintained.

 
Gruß Axel

MadMetzger:
Mit iBatis habe ich mich noch nicht beschäftigt, aber immerhin kann man Hibernate ja auch ein paar Dinge vorgaukeln, denn beispielsweise bei versionierten Daten greift man im Normalfall immer mit dem aktuellen Datum als Bezugspunkt zu, so dass im Regelfall hier nicht viele Probleme sind. Gerade Versionierung kann man hinter Views mit relativ wenig Aufwand verstecken, ohne tief in Hibernate einzusteigen. Hierbei ist es dann sogar egal, wer auf welche Art auf diese versionierten Daten zugreift, sofern er vorher eben dem "System" seinen Bezugspunkt mitgeteilt hat. Ich habe das hier mit einem Kollegen so implementiert, dass wir in der Lage sind, ein beliebiges relationales Schema so zu transformieren, dass es dem schon bestehenden Code untergeschoben werden kann.

Man muss halt wissen, was man tut. Wenn man Hibernate etwas "vorgaukelt", muss man sich im klaren sein, dass dies an anderer Stelle zu Problemen führen wird. Aber wenn man eine Sache zu Ende denkt, dann geht das schon ganz gut. Aber man muss halt wirklich wissen, was man tut...

Was ich mir noch von einem O/R-Mapper wünschen würde ist, dass er die Objekte in ein Meta-Modell abspeichern kann. Bisher habe ich das noch von keinem Mapper gesehen.

flaite:
Das hört sich ein bischen nach where Klauseln an. Also das kann HSQL.
Hab bestimmt 8 Monate nichts mehr mit Hibernate gemacht, aber ein Punkt auf den eigentlich alle stossen ist der n+1 select Klassiker. Und den kann man mit outer joins umschiffen. Hibernate ist nicht dafür da, um sich SQL zu sparen.
Speaking of...  ;D
Hier sind alle SQL Experten auf SAS Schulung im Urlaub oder ihnen werden Kinder geboren.
Zu meinem Problem:


--- Code: ---SELECT PE.MONEY - Sum(OD.PRICE * OD.AMOUNT)
FROM
PERSON PE, ORDERS OD
WHERE
OD.ID_TRADER = PE.ID
AND
PE.ID = #id#

--- Ende Code ---
Das ist ein join mit der Tabelle Person und der Tabelle Orders über PE.ID - ORDERS_ID_TRADER.
Manchmal gibt es aber zu der Person keine ORDERS, heisst SUM(OD.PRICE * OD.AMOUNT) ergibt null. Dummerweise ergibt dann er gesamte Ausdruck NULL, obwohl PE.Moner nicht NULL ist?

Du erwartest von den OR-Mappern eine Art Round-Trip Engineering für Model Driven Architecture. Ist es nicht eher die Idee von MDA, dass man von den Implementierungs-unabhängigen Modellen herunterarbeitet? Was ich so von MDA-Leuten gehört habe ist eher, dass die ziemlich round-trip engineering kritisch sind. Abgesehen ist Modell generieren schon gut. Spring IDE macht das jetzt ganz schön für Bean Container.

Navigation

[0] Themen-Index

[#] Nächste Seite