Kommentare für Thomas Schütt http://thomas-schuett.de Softwareentwickler und Architekt mit Schwerpunkt Enterprise Java Sat, 16 Jul 2011 21:45:05 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Kommentar zu Gute Gründe für die Programmierung eines eigenen Frameworks von Mattes http://thomas-schuett.de/2011/02/10/gute-grunde-fur-die-programmierung-eines-eigenen-frameworks/comment-page-1/#comment-204 Mattes Sat, 16 Jul 2011 21:45:05 +0000 http://thomas-schuett.de/?p=266#comment-204 Wundervoller Artikel. Leider schlaegt bei vielen der Sarkasmusdetektor nicht an. Wundervoller Artikel. Leider schlaegt bei vielen der Sarkasmusdetektor nicht an.

]]> Kommentar zu Datenbanken sind langsam von tschuett http://thomas-schuett.de/2010/10/25/datenbanken-sind-langsam/comment-page-1/#comment-188 tschuett Thu, 04 Nov 2010 11:21:36 +0000 http://thomas-schuett.de/?p=242#comment-188 Das nette an JPA ist, dass genau sowas damit total unproblematisch geht: Man baut sich einfach seine Abfrage zusammen und JPA ruft dann den entsprechenden Konstruktor des POJOs auf. <code>SELECT NEW beispiel.MeinDAO(c.name, c.hauptstadt.name) FROM Land AS c</code> Die Klasse muss eben nur den entsprechenden Konstruktor aufweisen. Wenn die JPQL abfragen sinnvoll formuliert sind, reicht es nach meiner Erfahrung schon für einen Großteil der Anwendungen dort draußen (auch gerne mit mehreren hundert parallelen Benutzern). Für Spezialfälle lassen sich die JPQL Queries aber auch durch "native" SQL Queries überschreiben und der Code bleibt portabel. Ganz nett, wenn bestimmte Komponenten strategisch auf eine günstigere DB umgezogen werden sollen. Der Vorschlag von mir ist nicht, auf das Framework zu verzichten, sondern es zu benutzen und überdas Framework arbeit an die Datenbank auszulagern. Wenn ich mich für Java EE entscheide, habe ich den ganzen Luxus ja schon. Wozu sollte ich das Rad neu erfinden - außer ich bin facebook oder so was irres - aber dann funktioniert generell nichts von der Stange. Das nette an JPA ist, dass genau sowas damit total unproblematisch geht: Man baut sich einfach seine Abfrage zusammen und JPA ruft dann den entsprechenden Konstruktor des POJOs auf.
SELECT NEW beispiel.MeinDAO(c.name, c.hauptstadt.name) FROM Land AS c
Die Klasse muss eben nur den entsprechenden Konstruktor aufweisen. Wenn die JPQL abfragen sinnvoll formuliert sind, reicht es nach meiner Erfahrung schon für einen Großteil der Anwendungen dort draußen (auch gerne mit mehreren hundert parallelen Benutzern). Für Spezialfälle lassen sich die JPQL Queries aber auch durch “native” SQL Queries überschreiben und der Code bleibt portabel. Ganz nett, wenn bestimmte Komponenten strategisch auf eine günstigere DB umgezogen werden sollen.
Der Vorschlag von mir ist nicht, auf das Framework zu verzichten, sondern es zu benutzen und überdas Framework arbeit an die Datenbank auszulagern. Wenn ich mich für Java EE entscheide, habe ich den ganzen Luxus ja schon. Wozu sollte ich das Rad neu erfinden – außer ich bin facebook oder so was irres – aber dann funktioniert generell nichts von der Stange.

]]> Kommentar zu Datenbanken sind langsam von Hans Müller http://thomas-schuett.de/2010/10/25/datenbanken-sind-langsam/comment-page-1/#comment-187 Hans Müller Wed, 03 Nov 2010 23:32:10 +0000 http://thomas-schuett.de/?p=242#comment-187 wo du recht hast, hast du recht! hibernate & konsorten sind zwar angenehm zum entwickeln, was die geschwindigkeit betrifft allerdings unterste schublade... für anwendungen mit vielen usern gleichzeitig kaum zu gebrauchen. wenn schon hibernate, dann am besten die beans ("dto") für einen join erstellen, kein "rohes" crud (create, read, update, delete) wo man für einen read-vorgang für jeweils eine abfrage SELECT * FROM Tabellenname macht, und anschliessend das ganze in 2 java.util.List's, gefüllt mit dto's, gegeneinander in 2 for-schleifen vergleicht... z.b. um einen join nachzubilden... wenn ich unbedingt sowas haben will, bastle ich mir das ganze eh selber, steh nicht so auf frameworks. dabei mache ich eine konstruktion aus dao's (crud-grundoperationen), dto's und einem service-layer für komplette db-operationen. gruss, hans wo du recht hast, hast du recht! hibernate & konsorten sind zwar angenehm zum entwickeln, was die geschwindigkeit betrifft allerdings unterste schublade… für anwendungen mit vielen usern gleichzeitig kaum zu gebrauchen.

wenn schon hibernate, dann am besten die beans (“dto”) für einen join erstellen, kein “rohes” crud (create, read, update, delete) wo man für einen read-vorgang für jeweils eine abfrage SELECT * FROM Tabellenname macht, und anschliessend das ganze in 2 java.util.List’s, gefüllt mit dto’s, gegeneinander in 2 for-schleifen vergleicht… z.b. um einen join nachzubilden…

wenn ich unbedingt sowas haben will, bastle ich mir das ganze eh selber, steh nicht so auf frameworks. dabei mache ich eine konstruktion aus dao’s (crud-grundoperationen), dto’s und einem service-layer für komplette db-operationen.

gruss, hans

]]> Kommentar zu Ordered Lists in JPA – Do it yourself von tschuett http://thomas-schuett.de/2008/11/14/ordered-lists-in-jpa-do-it-yourself/comment-page-1/#comment-182 tschuett Sat, 31 Jul 2010 11:20:04 +0000 http://thomas-schuett.de/?p=45#comment-182 Danke! Der Artikel ist halt noch aus pre 2.0 Zeiten ;-) Sehr schöne Domain übrigens ;-) Danke! Der Artikel ist halt noch aus pre 2.0 Zeiten ;-) Sehr schöne Domain übrigens ;-)

]]> Kommentar zu Ordered Lists in JPA – Do it yourself von DaJunkie http://thomas-schuett.de/2008/11/14/ordered-lists-in-jpa-do-it-yourself/comment-page-1/#comment-180 DaJunkie Mon, 05 Jul 2010 19:27:38 +0000 http://thomas-schuett.de/?p=45#comment-180 In JPA 2.0 gibt es die Annotation @OrderColumn. Mit dieser verhalten sich persistente Lists wieder genau so, wie man es als Java-Programmierer erwartet :) In JPA 2.0 gibt es die Annotation @OrderColumn. Mit dieser verhalten sich persistente Lists wieder genau so, wie man es als Java-Programmierer erwartet :)

]]> Kommentar zu Glassfish 3.1 mit Cluster Support noch in diesem Jahr von admin http://thomas-schuett.de/2010/03/29/glassfish-3-1-mit-cluster-support-noch-in-diesem-jahr/comment-page-1/#comment-179 admin Wed, 28 Apr 2010 20:52:02 +0000 http://thomas-schuett.de/?p=216#comment-179 Das finde ich - aus ganz ähnlichen, uneigennützigen Gründen - auch :-) Das finde ich – aus ganz ähnlichen, uneigennützigen Gründen – auch :-)

]]> Kommentar zu Glassfish 3.1 mit Cluster Support noch in diesem Jahr von IP-Projects http://thomas-schuett.de/2010/03/29/glassfish-3-1-mit-cluster-support-noch-in-diesem-jahr/comment-page-1/#comment-178 IP-Projects Wed, 28 Apr 2010 15:00:24 +0000 http://thomas-schuett.de/?p=216#comment-178 Super Sache :) Super Sache :)

]]> Kommentar zu EJBs von Lift aufrufen von blog » Scala EJB http://thomas-schuett.de/2010/02/05/ejbs-von-lift-aufrufen/comment-page-1/#comment-141 blog » Scala EJB Mon, 08 Feb 2010 13:22:03 +0000 http://thomas-schuett.de/?p=186#comment-141 [...] Update: Der weg von Scala (Lift) zum EJB steht hier. [...] [...] Update: Der weg von Scala (Lift) zum EJB steht hier. [...]

]]> Kommentar zu Agile Entwicklung von Frank Pfabigan http://thomas-schuett.de/2009/03/29/agile-entwicklung/comment-page-1/#comment-14 Frank Pfabigan Mon, 27 Apr 2009 08:23:09 +0000 http://thomas-schuett.de/?p=111#comment-14 Tja, reichen wir uns die Hände ;-) Entwicklungen für Kunden laufen meistens nach diesem Schema ab, ob gewollt oder nicht. Daß man unter Umständen erst einmal die Basis, z.B. eine aufwändige Datenbank und die Scripte, die für den Transport der Daten sorgen, schreiben muß, interessiert nicht. Der Kunde will zuerst die GUI, alles andere interessiert ihn nicht. Er verdreht dabei den Entwicklungsweg und macht dem Entwickler das Leben (unnötig) schwer. Besonders schlimm bei Webprojekten, die direkt im Browser laufen: sowas wird als "einfach" angesehen, das kann ja wohl nicht so schwer sein, mal eben die Designfarben umzustellen... seufz. Ich kann den Kunden verstehen, aber andererseits fühle ich mich auch ein wenig "gekränkt" (nicht das richtige Wort, ist zu früh, hab bis 03:00 Uhr an was gesessen): Kunde beauftragt "Fachkraft" und schreibt diesem die Arbeitsweise vor. Das gibt es wohl nur bei Software und besonders auch bei Web/Print. Kein Kunde würde doch auf die Idee kommen, beim Zahnarzt einen Holzzahn zu verlangen... Warum dann bei Entwicklern? Wenn man viele Projekte parallel bearbeitet, wird das zusätzliche "betütern" zu einem echten Zeitfaktor und bringt die ganze Planung durcheinander. Nicht ganz zufriedenstellend für mich. Aber ändern/erziehen kann man den Kunden nicht. Schlußendlich zahlt der Kunde (hoffentlich) dafür. Also muß man einen gangbaren Weg finden. Ich bin lange weg von "Projektmanagement-Methoden", bringt nix. Jeder Auftrag ist "Einzelverhandlungssache und -gebastel". Glückauf ;-) Tja, reichen wir uns die Hände ;-)
Entwicklungen für Kunden laufen meistens nach diesem Schema ab, ob gewollt oder nicht. Daß man unter Umständen erst einmal die Basis, z.B. eine aufwändige Datenbank und die Scripte, die für den Transport der Daten sorgen, schreiben muß, interessiert nicht.
Der Kunde will zuerst die GUI, alles andere interessiert ihn nicht. Er verdreht dabei den Entwicklungsweg und macht dem Entwickler das Leben (unnötig) schwer.
Besonders schlimm bei Webprojekten, die direkt im Browser laufen: sowas wird als “einfach” angesehen, das kann ja wohl nicht so schwer sein, mal eben die Designfarben umzustellen… seufz.
Ich kann den Kunden verstehen, aber andererseits fühle ich mich auch ein wenig “gekränkt” (nicht das richtige Wort, ist zu früh, hab bis 03:00 Uhr an was gesessen):
Kunde beauftragt “Fachkraft” und schreibt diesem die Arbeitsweise vor. Das gibt es wohl nur bei Software und besonders auch bei Web/Print.
Kein Kunde würde doch auf die Idee kommen, beim Zahnarzt einen Holzzahn zu verlangen… Warum dann bei Entwicklern?
Wenn man viele Projekte parallel bearbeitet, wird das zusätzliche “betütern” zu einem echten Zeitfaktor und bringt die ganze Planung durcheinander. Nicht ganz zufriedenstellend für mich. Aber ändern/erziehen kann man den Kunden nicht. Schlußendlich zahlt der Kunde (hoffentlich) dafür. Also muß man einen gangbaren Weg finden. Ich bin lange weg von “Projektmanagement-Methoden”, bringt nix. Jeder Auftrag ist “Einzelverhandlungssache und -gebastel”.
Glückauf ;-)

]]> Kommentar zu Java EE 6 – Viele Antworten auf alte Fragen von tschuett http://thomas-schuett.de/2008/09/17/java-ee-6-viele-antworten-auf-alte-fragen/comment-page-1/#comment-6 tschuett Wed, 19 Nov 2008 14:08:22 +0000 http://thomas-schuett.de/?p=30#comment-6 Lustiger Vortrag. Adam ist schon ein Original :-) Lustiger Vortrag. Adam ist schon ein Original :-)

]]>