Warum Java diese komischen Frameworks so beliebt sind

[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!!!!!
				
			}
		}
	}

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");
	}

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>

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

 

[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... 
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#

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.

[MadMetzger]

Also eigentlich würde ich mich nicht als "Round-Trip-Engineering-Fan" sehen. Ich präferiere eher die Variante des "Hinzufügens" von einzelnen "Komponenten" zu einem Fachmodell, das als Basis dient. Beispielsweise ist das Einbauen der Persistenz solch ein Schritt, oder wenn man dafür sorgen will, dass ein Fachmodell "observierbar" wird. Wahrscheinlich hast du mit deiner Aussage auf meinen "Wunsch" nach einem Mapper in ein Meta-Modell angespielt, oder? Dann hast du mich da etwas missverstanden. Mir ging es da eher um eine von "3,5" möglichen Strategien, ein Objektmodell in eine relationale Datenbank abzubilden. Wer Fowlers "Patterns of Enterprise Application Architecture" gelesen hat, wird die ersten "2,5" davon wiedererkennen (Mal so aus dem Gedächtnis hingeschrieben):

• Single-Table-Inheritance: Alle Klassen einer Hierarchie in eine Tabelle
• Class-Table-Inheritance

• Concrete-Class-Table-Inheritance: Je konkrete Klasse eine Tabelle, Attribute der Oberklassen werden "ausmultipliziert"
• One-Table-Per-Class: Eine Tabelle je Klasse, Vererbungsbeziehung per Fremdschlüssel(also Delegation auf Tabellenebene)

• Meta-Modell: Abbildung der Klassenstruktur in ein Meta-Modell mit Tabellen für Typen, Assoziationen, Vererbung, Objekte, Verknüpfungen und Werte (für "primitive" Typen wie Strings)

Solch ein Mapper ist mir bisher halt nicht bekannt... Kann man sich aber selbst schreiben... Ansonsten können wir das bei einem Bier diskutieren, wenn du mal in Hannover bist... 

Mit Hibernate spart man sich auch nicht wirklich SQL, unser Ansatz war halt, da wir eben erstmal isoliert entwickeln wollten, dass man dieses Verhalten tief in die Datenbank schiebt. Wahrscheinlich sind Views auch nicht der Weisheit letzter Schluss, vielleicht wären StoredProcedures sogar noch eine bessere Wahl. Aber in letzterem Fall hätten wir eben recht viel an anderen Stellen verändern müssen, was so noch nicht gewünscht war.

[flaite]

Wer Fowlers "Patterns of Enterprise Application Architecture" gelesen hat, wird die ersten "2,5" davon wiedererkennen (Mal so aus dem Gedächtnis hingeschrieben):

• Single-Table-Inheritance: Alle Klassen einer Hierarchie in eine Tabelle
• Class-Table-Inheritance

• Concrete-Class-Table-Inheritance: Je konkrete Klasse eine Tabelle, Attribute der Oberklassen werden "ausmultipliziert"
• One-Table-Per-Class: Eine Tabelle je Klasse, Vererbungsbeziehung per Fremdschlüssel(also Delegation auf Tabellenebene)

• Meta-Modell: Abbildung der Klassenstruktur in ein Meta-Modell mit Tabellen für Typen, Assoziationen, Vererbung, Objekte, Verknüpfungen und Werte (für "primitive" Typen wie Strings)

Solch ein Mapper ist mir bisher halt nicht bekannt... Kann man sich aber selbst schreiben... Ansonsten können wir das bei einem Bier diskutieren, wenn du mal in Hannover bist... 

Aber man kann die alle mit Hibernate implementieren. Hat aber natürlich nicht den Namen des Patterns in dem Hibernate-Metadata.
http://www.hibernate.org/hib_docs/reference/en/html/inheritance.html

Mit Hibernate spart man sich auch nicht wirklich SQL, unser Ansatz war halt, da wir eben erstmal isoliert entwickeln wollten, dass man dieses Verhalten tief in die Datenbank schiebt. Wahrscheinlich sind Views auch nicht der Weisheit letzter Schluss, vielleicht wären StoredProcedures sogar noch eine bessere Wahl. Aber in letzterem Fall hätten wir eben recht viel an anderen Stellen verändern müssen, was so noch nicht gewünscht war.

Verschiebt ihr nicht mit beiden Lösungen die Implementierung auf eine low-level Ebene. Man kann das wie gesagt auch im Hibernate Modell definieren. Ich hab z.B. auch ein Single-Table-Inheritance: Alle Klassen einer Hierarchie in eine Tabelle in meinem IBatis Modell.

Code

	<resultMap id="person" class="de.spintegration.fussi.bo.Person">
			<result property="id" column="ID"/>
			<result property="name" column="NAME"/>
			<result property="pwd" column="PWD"/>
			<result property="email" column="EMAIL"/>
			<discriminator column="TYPE" javaType="String">
				<subMap value="Trader" resultMap="trader"/>
				<subMap value="Admin" resultMap="admin"/>
			</discriminator>
	</resultMap>
	
	<resultMap id="trader" class="de.spintegration.fussi.bo.Trader" extends="person">
		<result property="money" column="MONEY"/>
	</resultMap>

	<resultMap id="admin" class="de.spintegration.fussi.bo.Admin" extends="person">
	</resultMap>

wobei im Objekt-Modell Trader extends Person und Admin extends Person 

Ansonsten können wir das bei einem Bier diskutieren, wenn du mal in Hannover bist...

Gerne. Nur bin ich da praktisch nie. Freunde von mir bezeichnen meinten schon, ich wär sowas wie die Luxusausführung eines chinesischen Wanderarbeiters.

[MadMetzger]

Wer Fowlers "Patterns of Enterprise Application Architecture" gelesen hat, wird die ersten "2,5" davon wiedererkennen (Mal so aus dem Gedächtnis hingeschrieben):

• Single-Table-Inheritance: Alle Klassen einer Hierarchie in eine Tabelle
• Class-Table-Inheritance

• Concrete-Class-Table-Inheritance: Je konkrete Klasse eine Tabelle, Attribute der Oberklassen werden "ausmultipliziert"
• One-Table-Per-Class: Eine Tabelle je Klasse, Vererbungsbeziehung per Fremdschlüssel(also Delegation auf Tabellenebene)

• Meta-Modell: Abbildung der Klassenstruktur in ein Meta-Modell mit Tabellen für Typen, Assoziationen, Vererbung, Objekte, Verknüpfungen und Werte (für "primitive" Typen wie Strings)

Solch ein Mapper ist mir bisher halt nicht bekannt... Kann man sich aber selbst schreiben... Ansonsten können wir das bei einem Bier diskutieren, wenn du mal in Hannover bist... 

Aber man kann die alle mit Hibernate implementieren. Hat aber natürlich nicht den Namen des Patterns in dem Hibernate-Metadata.
http://www.hibernate.org/hib_docs/reference/en/html/inheritance.html

Leider kann Hibernate gerade diese letzte Strategie "Meta-Modell" nicht. Die ersten "2,5" kann es, habe ich zum Teil auch selbst schonmal verwendet. Bei der Umsetzung hätte Hibernate den Vorteil, dass es die Tabellenstruktur von vornherein schon kennen würde, da es sich nach dem Bild im Anhang richten kann (Ja, das Diagramm wird dann als Class-Table abgebildet).

Verschiebt ihr nicht mit beiden Lösungen die Implementierung auf eine low-level Ebene. Man kann das wie gesagt auch im Hibernate Modell definieren. Ich hab z.B. auch ein Single-Table-Inheritance: Alle Klassen einer Hierarchie in eine Tabelle in meinem IBatis Modell.

Das ist richtig, dass wir die Versionierung und Historisierung bisher ganz tief in die Datenbank verlagern. Aber zumindest die Historisierung von Daten lässt sich, soweit ich das jetzt nach längerem Nachdenken überblicken kann, nicht vor der restlichen Logik verstecken. Das liegt aber eben an der fachlichen Natur von Historisierung.

wobei im Objekt-Modell Trader extends Person und Admin extends Person 

Was ich auf den allerersten Blick für keine "gute" Vererbungsbeziehung halten würde... Aber dazu kenne ich den Hintergrund ja nicht... Würde das eher so sehen, dass Personen Rollen haben. Und diese Rollen sind dann eben Trader oder auch Admin. Bei der Vererbungsbeziehung kann eine Person nicht beides gleichzeitig sein. SCNR

Ansonsten können wir das bei einem Bier diskutieren, wenn du mal in Hannover bist...

Gerne. Nur bin ich da praktisch nie. Freunde von mir bezeichnen meinten schon, ich wär sowas wie die Luxusausführung eines chinesischen Wanderarbeiters.

Witzige Bezeichnung... Aber wenn du mal da sein solltest, wäre das mal eine Idee...

[flaite]

Was ich auf den allerersten Blick für keine "gute" Vererbungsbeziehung halten würde... Aber dazu kenne ich den Hintergrund ja nicht... Würde das eher so sehen, dass Personen Rollen haben. Und diese Rollen sind dann eben Trader oder auch Admin. Bei der Vererbungsbeziehung kann eine Person nicht beides gleichzeitig sein. SCNR

Person ist abstract. Eine Person kann nicht Trader UND Admin sein.

[MadMetzger]

Naja, egal... Ich finde nur das Erben von einer Fachklasse "Person" nicht unbedingt gut, aus den von mir genannten Gründen. Aber hier kann das auch ganz anders sein... Bin da irgendwie ein bißchen drauf getrimmt, mir solche Modellierungen zu durchdenken...

[flaite]

Beide teilen sich nur die gemeinsame Authentifizierung. Ansonsten sind sie Akteure in völlig unterschiedlichen Anwendungsfällen. Ausserdem schliessen sie sich gegenseitig aus. Dh. ein Admin kann kein Trader sein und umgekehrt.
Das benutzt übrigens sowieso als fachlich nicht besonders reichhaltige Webanwendung anemic domain model.
Die Geschäftslogik befindet sich weitestgehend in einer z.T. heftig prozeduralen transaktionale Service Schicht, die wiederum eine DAO-Schicht und (bald) Messaging über Active MQ benutzt. Ich glaub, das ist für die Anwendung einfacher, hab aber auch meine Zweifel. Mit AOP hätte ich das zweifellos mehr OO gekriegt. Aber ich mach das in einem Kurs für gute Domino Entwickler und IBM Enterprise Zeugs/C Experten (Websphere MQ, DB2) und es ist so schon schwierig die innerhalb des kurzen Zeitbudgets nicht zu überrollen.
 
Im Vordergrund stehen auch eher infrastrukturelle Fragen wie die Auslotung der Einbindung einer Messaging Infrastruktur und dem für mich neuen Thema Spring Security.

[MadMetzger]

Das dachte ich mir schon fast, dass das Fachmodell dort nicht im Vordergrund steht. Ist ja in diesem Fall auch wirklich nicht so wichtig, wenn es um andere Themen geht...