Java + Hibernate + MySQL

Hallo,

Ich wollte mal fragen ob es Browsergames gibt, welche mit Java + Hibernate (ORM Framework) + MySQL entwickelt sind. Ob jetzt Java mit Servlets/JSP oder einem Framework wie Spring oder JSF implementiert ist, spielt keine Rolle.

Ich sehe eigentlich nur PHP Entwicklungen und frage mich ob die von mir genannte Kombination überhaupt Sinn für ein Browsergame machen würde.

Welche Vorteile hat PHP gegenüber Java bei der Umsetzung?
Wie gross ist eigentlich der Unterschied bei der Geschwindigkeit, wenn Java + SQL vs Java + Hibernate (oder sonst ein Persistenzframework) antritt?

HiHo...

Ich entwickle http://overwatch.de, welches serverseitig in Java geschrieben ist. Mein Technologiestack besteht hauptsächlich aus Stripes, Spring, Hibernate und die Anwendung läuft in einem Tomcat.

Sinn macht eigentlich alles, womit du umgehen kannst und das dir html, xml oder json ausliefert. Jede Technologie hat ihre Vor- und Nachteile. Nimm einfach das, mit dem du umgehen kannst...ich nehme mal an, dass du eh ein "Ein-Mann-Hobbyprojekt" bist.

Zu deiner Frage bezüglich der Performance:

Wenn du direkt Java und SQL benutzt, dann hast du auch die 100%ige Kontrolle darüber was du für Querys auf die DAtenbank loslässt. Du siehst immer genau, was du machst und kannst abschätzen, ob jetzt viele oder wenige Querys abgelassen werden. Ob diese Querys sehr gross sind und z.B. wie viele Joins drin enthalten sind.

Das alles versteckt Hibernate vor dir und wenn du dich nicht genau damit auseinandersetzt, wie es funktionert, dann wirdst du Performanceprobleme bekommen...garantiert.  Glaube mir, es gibt viele Möglichkeiten sich mit Hibernate Performancelöcher zu schaufeln. Du hast aber auch viele Möglichkeiten deine Anwendung durch Hibernate richtig schnell zu bekommen. Z.B. sammelt Hibernate updates an deinen Entitäten und schreibt diese erst du einem möglichst späten Zeitpunkt gesammelt zurück. In deinem Java+SQL Szenarion müsstest du dir das für jeden Use-Case selbst bauen. Hibernate verfügt über einen 2nd Level Cache, der optional dazugeschaltet werden kann. Du kannst diesen sogar verteilen, wenn es notwendig ist.

Wenn man davon ausgeht, dass du Hibernate verstanden hast und nur die reine Performance vergleicht, dann ist Hibernate im Vergleich zu nativen SQL natürlich langsamer. Aber so what...der Mörderlteil der Zeit wird durch die Datenbankabfrage verbraucht. Der Rest ist so klein, dass er nicht wirklich ins Gewicht fällt.  Ich würde in jedem Fall Hibernate einer Anwendung, die direkt SQL verwendet vorziehen. Die Vorteile überwiegen einfach deutlich.

Mr.Maxx

Original von ElComanche

Hallo,

Ich wollte mal fragen ob es Browsergames gibt, welche mit Java + Hibernate (ORM Framework) + MySQL entwickelt sind. Ob jetzt Java mit Servlets/JSP oder einem Framework wie Spring oder JSF implementiert ist, spielt keine Rolle.

Ich sehe eigentlich nur PHP Entwicklungen und frage mich ob die von mir genannte Kombination überhaupt Sinn für ein Browsergame machen würde.

Welche Vorteile hat PHP gegenüber Java bei der Umsetzung?
Wie gross ist eigentlich der Unterschied bei der Geschwindigkeit, wenn Java + SQL vs Java + Hibernate (oder sonst ein Persistenzframework) antritt?

Ich kann mir irgendwie kaum vorstellen, dass sich hier (viele) Entwickler befinden, die ein derart großes Browsergame am Start haben, ab dem sich der Einsatz von Java/Hibernate lohnen würde. Fehlende Schnittmenge..

Wenn man es richtig macht, und seine Tools und Frameworks beherrscht, kann mit beispw. mit Hibernate viel Zeit sparen - aber bei Unkenntnis von SQL und Arbeitsweise des Frameworks die DB performancetechnisch an die Wand fahren.

Edit: Okay, doch einer. Aber abgesehen von kleinen Projekten oder Hobby-Spiel mit xx-Leuten?

Ich habe bereits ein BG gesehen, welches sich zumindest auf den ersten Blickund teilweise als JAVA ausweist, ein Teil der URLs in diesem BG endeten auf *.jsp, die anderen auf *.php. Welche technologien dort tatsächlich eingesetzt waren und warum das so aussah weiß ich nicht, das BG hatte mir nicht wirklich gefallen, weswegen ich es schnell wieder verlassen habe, ich errinnere mich auch nicht mehr an den Namen.

Ich könnte mir allerdings vorstellen, daß JAVA als Servertechnologie schneller ist als PHP. Denn JAVA wird ja nur beim ersten Aufruf oder bei Änderungen neu kompiliert, PHP dagegen (ohne ZEND-Extensions, oder?) ja bei jedem aufruf erneut geparsed wird.

Ansonsten wäre aber ein für mich entscheidender Vorteil von JAVA die Standardlib. Diese ist wesentlich aufgeräumter als die PHPs, aufgrund des grundsätzlich anderen Ansatzes allerdings schwerer zu erlernen... Ich hatte mir JAVA mal angesehen mit JSP und ich bin kaum über die Tutorials herausgekommen, weil ich einfach nicht hinter die internen Zusammenhänge gekommen bin :-(

Für mein aktuelles, noch namenloses, Projekt probiere ich alle paar Wochen eine neue Sprache/Konzept/Framework aus indem ich anhand von Tutorials erst einmal das ausprobiere und im Anschluss einen kleinen Twitter selbst code. Am Ende werde ich mich dann für die Kombination entscheiden die für mich persönlich am einfachsten ist.

Im Moment steht hier C# mit ASP.net hoch im Kurs, aber ich will mir da erst noch die Möglichkeiten von C# 4.0 und .net 4.0 ansehen bevor ich eine endgültige Entscheidung fälle, zumal ich hier immer noch große Probleme mit den Datenbanken habe diese erstmalig zu konfigurieren. Für die Entwicklung und zum testen reicht SQLite aber Produktiv würde ich dann schon gerne auf nen MS SQL verbinden und irgendwie gelingt mir das in meiner Testumgebung nicht, und irgendwie sieht mein Studio auch immer anders aus als in den Tutorials :-(

Aber ich schweife ab :-)

Ich kenne zumindest ein größeres Spiel, das Server-Seitig in Java geschrieben ist. Wenn ich noch mal ein BG entwickeln würde, würde ich mich wahrscheinlich für Java oder Scala entscheiden. Ich denke die Plattform ist einfach "reifer" als PHP oder Ruby. Java ist mir persönlich immer etwas zu gesprächig und die Möglichkeiten der Abstraktionen relativ klein. Dafür sucht der Support an Tools und Libraries sicher seines Gleichen und die Sprache ist relativ einfach zu erlehrnen.
Ich glaube viele Hobbyisten verwenden einfach PHP, weil es da günstigen Webspace gibt.
Von C# würde ich persönlich die Finger lassen. 'Ne Mischung aus Delphi und Java, die kaum Vorteile mit sich bringt, an eine Plattform nagelt.

Ich sehe in C# keinerlei verwandschaft zu PASCAL, wie bitte komst Du auf den schmalen grad? Und auch JAVA ist "nur" ein abgucker von C++, also was solls?

Und mit C#-Sharp binde ich mich nicht an eine Plattform, und auch mit .net nur bedingt. Sollte ich mich am Ende für .net 3.0 entscheiden kann ich es (fast) ohne einschränkungen auch auf nem Linux laufen lassen, dafür gibt es Mono. Auch kleine Teile von .net 3.5 waren bei meinem letzten Blick auf mono bereits umgesetzt. Natürlich muss ich die Schnittmenge immer beachten wenn ich eine spätere portierbarkeit erhalten möchte, aber da muss man auch bei Java aufpassen, man muss ja nur mal ne externe Lib einbinden die JNI nutzt und schon hat man Krach.

C# besitzt nun mal ein Sprachfeature, daß mich alle anderen Sprachen (fast) vergessen lässt. LINQ, Language Integrated Querys, egal ob ich eine bestimmte Information aus einer Datenbank, einer XML-Datei oder einfach nur aus einer Datenstruktur extrahieren will, ich nutze das gleiche Sprachkonstrukt, welches an SQL rückwärts erinnert.

Aber ich glaube das ist einfach Gewohnheits-/Glaubenssache :-) Hauptsache kein PHP ;-)

> 'Ne Mischung aus Delphi und Java, die kaum Vorteile mit sich bringt, an eine Plattform nagelt

?!

Eine Plattform?

Du kennst Mono und Mono läuft unter Windows, Linux, iPhone, iPod Touch, iPad und auch zum Teil auf der Wii (mit unterschiedlichen Kompilationsstufen). Damit ist C# zum Teil portabler als Java.

Du kannst .Net als plattformabhängig bezeichnen (auch wenn es von der Xbox über den PC bis zum Handy läuft), aber C# und damit auch Mono auf keinen Fall.

> Java [...] und die Möglichkeiten der Abstraktionen relativ klein

Ich hoffe, dass das Ironie war.

> Du kennst Mono und Mono läuft unter Windows, Linux, iPhone, iPod Touch, iPad und auch zum Teil auf der Wii (mit unterschiedlichen Kompilationsstufen). Damit ist C# zum Teil portabler als Java.
C# braucht das .net Framework und das ist wohl kaum auf jeder Plattform verfügbar. Ich selbst muss gerade eine C# GUI unter WinCE warten und selbst da sind die Abstriche gegenüber der Desktop-Version enorm. Viele Funktionen, die im Compactframework fehlen musss man sich einfach selbst schreiben und die sind zum Teil so elementar, dass man sich schon vorstellen kann, dass es da bereit sicher hunderte von Implementierungen einzelnder Funktionen gibt. Eine Sprache, die einfach so in der Luft hängt, ohne die Möglichkeit, portabel mit der Umwelt zu komuniziern, taugt ja nicht viel, also muss man mal die Libraries mit betrachten, vor allem, wenn es sehr wenige gibt, was für eine so junge Sprache natürlich normal ist. Selbst wenn Sun irgend wann man beschließt, Java nicht mehr zu unterstützen, ist in Java Code so viel Geld investiert, dass sehr wahrscheinlich ist, dass es für Java sehr sehr lange Support geben wird.
>> Java [...] und die Möglichkeiten der Abstraktionen relativ klein
> Ich hoffe, dass das Ironie war.
Nein, das war erst gemeint. Mein "Brott und Butter" Sprache ist C++ und damit kann man in der Regel das gleiche mit 1/3 weniger Code implementieren (für Ruby wäre das Verhältnis noch extremer). C++ templates sind doch noch einiges mächtiger als Javas generics (ganz zu schweigen, von dem Schwachsinn, den es da in C# gibt) und das Weglassen von Operatoren in Java, weil man damit auch Blödsinn machen kann, ist meiner Meinung nach ein Fehler. Schönes Beispiel wäre z.B. boost/spirit, eine Library, mit der man Parser, mit einer recht nah an EBNF angelehnten Syntax, beschreiben/implementieren kann. Das Problem von Java wurde ja auch schon erkannt und als Anlass genommen, Scala zu entwickeln.

Mit Java kenne ich mich aus. C#, C oder c++ fallen hier weg, vorallem für die Webprojekte.

Mit Hiberante beschäftige ich mich erst seit kurzer Zeit, aber es ist schon nice, wenn man durchgehend bei einem Projekt alles mit Objekten umsetzen kann, obwohl manche Sachen mit SQL schneller "durchzudenken" sind.

Hosting ist schon etwas problematischer, wenn man sich nur die grossen 0815 Anbieter mit ihren Produkten anschaut.

Erzählt weiter von euren Erfahrungen bezüglich Java :)

Original von Todi42

Mein "Brott und Butter" Sprache ist C++ und damit kann man in der Regel das gleiche mit 1/3 weniger Code implementieren

Ob das ganze dann noch les- und wartbar bleibt ist die Frage...besonders im Hinblick auf jemanden, der neu zu einem Projekt hinzustösst. Nur weil man etwas machen kann heisst es nicht, das es auch immer gleich (oder schlechter) besser ist. Grade C++ lässt seinem Benutzer die "Freiheit" komplett unleserlich zu werden.

Dass ich in Java meine Operanden nicht überschreiben kann sehe ich persönlich nicht als Nachteil an. Mag sein, dass ich bestimmte Dinge dadurch nur umständlicher realisieren kann, aber wenigstens ist mein Code immernoch verständlich, auch wenn ich nach einem Jahr nochmal draufgucke. Und nein ich möchte damit nicht ausdrüchen, dass C++ dadurch in irgendeiner Weise schlecht ist. Jedes Werkzeug hat seine Anwendung und hier geht es um die Entwicklung von Browsergames. Da das Argument der nicht überschreibbaren Operanden anzuführen ist...na ja...ich würds verstehen, wenn wir über was anderes reden würde...

Aber es wundere ich mich doch, warum Java mit seinen "relativ kleinen Möglichkeiten" der Abstraktion immernoch so beliebt ist... http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ... vermutlich haben die alle einfach keine Ahnung oder lösen nur nur ganz ganz einfache Probleme.

Bis denne...

Maxx

> C# braucht das .net Framework

Falsch...

C# braucht ein CLR-Framework.

Das gibt es in verschiedenen Ausprägungen: .Net, Silverlight, Mono, .Net Micro, .Net CE. CLR-Framework von Mono läuft auf mehr Plattformen als Java. Du nutzt halt mit WinCE ein nichtportables CLR-Framework.

Auch von Java gibt es verschiedene, inkompatible oder nur teilkompatible Frameworks. Sei mal SWT genannt, das es nicht für alle Java-Plattformen gibt, oder auch Kompatibilitätsprobleme zwischen OpenJDK und dem Sun JDK (das mit .Net vergleichbar ist).

Mono läuft im Übrigen auch auf dem Nokia-Handy.

Ich habe bewusst geschrieben: Mono und die C#-Implementation von Mono ist portabel und NICHT .Net ist portabel! Da steckt ein großer Unterschied drin! Genausowenig wie die Java-Implementation von Sun und die von Kaffe (http://de.wikipedia.org/wiki/Kaffe) kompatibel zueinander sind.

Dementsprechend müsste ich ja auch behaupten, dass Java nicht portabel ist, da es ja Java-Implementationen gibt, die nicht portabel sind und man nicht die Java-Frameworks blind austauschen kann. Es gibt auch nichtportable Java-Frameworks, die nur auf einer Maschine laufen.

> Javas generics (ganz zu schweigen, von dem Schwachsinn, den es da in C# gibt)

Java Generics und C#-Generics sind für den Entwickler nahezu identisch, allerdings werden C#-Generics vom .Net-Framework direkt unterstützt, während Java-Generics nur ein implizites TypeCasting während der Kompilierzeit ist. Im Regelfall erkennt man keinerlei Unterschiede zwischen Java- und C#-Generics und wenn doch, würde ich von dir gerne wissen warum C#-Generics Schwachsinn sind und Java-Generics nicht. C#-Generics haben, ausgenommmen des Wildcard-Platzhalters, keinerlei Nachteile gegenüber der Java-Generics.

Vielleicht solltest du dich mit der C#-Sache erstmal befassen, bevor du dagegen flamest.

> C++ templates sind doch noch einiges mächtiger als Javas generics

Und?

Annotations, bzw. Attribute sind die Königsklasse der Abstraktion! 99% der C++-Templates werden sowieso nur zur Typisierung genutzt. Das kann auch ein Generic.

Original von TheUndeadable

Du kennst Mono und Mono läuft unter Windows, Linux, iPhone, iPod Touch, iPad [...]

iP* ist leider raus: http://www.golem.de/1004/74361.html

@MrMaxx
> Grade C++ lässt seinem Benutzer die "Freiheit" komplett unleserlich zu werden.
Das gilt für jede Sprache. Bei C++ ist eher der Sprachumfang ein Problem. Wenn ich den Code eines anderen lesen will, dann muss ich natürlich die verwendeten Sprachkonstrukte kennen und dass können dann im Zweifelsfall alle sein. Ist die Sprache "kleiner", dann sind auch weniger Konstrukte zu lehrnen.
Operatoren in C++, Scala oder Ruby sind ja auch keine Magie, es sind einfach etwas speziellere Funktionsnamen. Ich kann jeder Funktion einen flaschen Namen geben bzw. dafür sorgen, dass Name und Implementierung noch zusammen passen. Aber allein die Tatsache, dass Klammern z.T. überflüssig werden, kann eine Sache dann schon wieder viel lesbarer machen: a + b + c; statt : a.add(b).add(c). Oder bei der Verwendung von boost/spirit
rule node = xml | *text; statt rule node = new sequence(nxml, new many(text));
Abstraktion funktioniert natürlich nur dann, wenn die Konzepte klar umgesetzt sind. Wenn ich einen Operator so implementiere, dass die Implementierung für Überraschungen sorgt, dann ist das ein Problem. Das Problem gibt es aber auch, wenn die Funktion einen "richtigen" Namen hat oder ich ein Interface falsch implmentiere.
> Jedes Werkzeug hat seine Anwendung und hier geht es um die Entwicklung von Browsergames. Da das Argument der nicht überschreibbaren Operanden anzuführen ist...na ja...ich würds verstehen, wenn wir über was anderes reden würde...
Ich wurde gefragt, ob ich es ernst meine, das mir persönlich Java zu wenig Abstraktionsmöglichkeiten bietet. Ich habe nicht argumentiert, dass Java sich aufgrund fehlender Operatoren nicht zum schreiben von Browser-Spielen eignet. Ich schrieb ja sogar, dass wenn ich noch mal ein BG schreiben würde, Java bei mir ganz oben wäre.
> Aber es wundere ich mich doch, warum Java mit seinen "relativ kleinen Möglichkeiten" der Abstraktion immernoch so beliebt ist...
Was hat das Eine mit dem Anderen zu tun? Du hast doch selbst geschrieben, dass Du gerne auf die eine oder andere Abstraktionsmöglichkeit verzichtest um die Verständlichkeit höher zu halten. Abstraktion bedeutet erst mal, Details zu verbergen oder Sachen zu komprimieren. Das muss ja nicht Jedermanns Sache sein. Scala geht mir da auch schon fast etwas zu weit.
@NobbZ
> Ich sehe in C# keinerlei verwandschaft zu PASCAL, wie bitte komst Du auf den schmalen grad?
Properties gab es so schon in Delphi 1. Ich glaube der Designer von C# war früher auch bei Borland (habs gerade in Wiki gefunden: Anders Hejlsberg; He was the original author of Turbo Pascal, the chief architect of Delphi, and currently works for Microsoft as the lead architect of the C# programming language).
@TheUndeadable
>> C# braucht das .net Framework
> Falsch...
> C# braucht ein CLR-Framework.
Gut, dann behaupte ich ab jetzt das Gegenteil. ;-)
> 99% der C++-Templates werden sowieso nur zur Typisierung genutzt. Das kann auch ein Generic.
In C++ können sowohl Klassen, als auch Funktionen und natürlich Member-Funktionen templates sein. template Parameter können neben Typen aber auch Konstanten und templates selbst sein. Neben Containern liefert die C++ Library z.B. auch noch ganz viele Algorithmen. Häufige Anwendung für templates ist auch statische polymorphie. Das kann man ähnlich wie "übliche" Polymorphie dann einsetzen, wenn bereits zur Übersetzungszeit die Typen fest stehen.
(BTW: Wenn einem Langweilig ist, kann man den C++ Compiler auch dazu bringen, das 8-Damen-Problem zu lösen: http://robitzki.de/eight_queens.html ;-)
Ich wollte niemandens Lieblingssprache diskreditieren. Meine Meinung von C# ist sicher auch stark von dem Stück Software, dass ich gerade warten muss, geprägt und die Autoren hätte in C++ wahrscheinlich ähnlichen Murks gebaut ;-)
mfg Todi

> Ich glaube der Designer von C# war früher auch bei Borland

Korrekt.

Bei Borland durfte er nicht soviel spielen und eigene Sprachkonstrukte erzeugen und durchsetzen. Bei MS scheint er recht freie Hand zu haben.

Und wer LINQ kennt, der weiß auch welche Blüten dies haben kann.

Beispiel in einem meiner Projekte

Man muss es nicht lieben, aber ich liebe es!

Original von TheUndeadable

Beispiel in einem meiner Projekte

Man muss es nicht lieben, aber ich liebe es!

OMG ich raff da überhaupt nichts :D

Original von buhrmi

Original von TheUndeadable

Beispiel in einem meiner Projekte

Man muss es nicht lieben, aber ich liebe es!

OMG ich raff da überhaupt nichts :D

Und das ist eines der Probleme in C#.

Obwohl C# eine 'Curly-Braced'-Sprache ist, besitzt es Sprachmerkmale, die in Augen vieler nichts darin zu suchen hat. Dies kritisieren einige an Hejlsberg. Es ist nicht mehr zwangsläufig intuitiv, obwohl viele C# nur für einen Java-Abklatsch halten.

Original von buhrmi

Original von TheUndeadable

Beispiel in einem meiner Projekte

Man muss es nicht lieben, aber ich liebe es!

OMG ich raff da überhaupt nichts :D

Das sieht doch in HQL nicht wesentlich anders aus -- wenn man jetzt mal die Sprache und die API aussen vorlässt. "Old school" SQL ist zwar direkter, aber dafür eben auch bloated.

Wobei das im konkreten Beispiel wohl eine XML-Basis ist.. äh, oder? :P Weil das kann ich jetzt auch nicht wirklich erkennen...

Ich find das embedded SQL in Abap viel schöner als LINQ (auch wenn die Sprache sonst müll ist):

SELECT feld1, feld2  IN $hashmap FROM tabelle JOIN ... WHERE feld3 = $var3

Ich sehe in dem Pseudo-SQL einfach keinen Mehrwert.

Falls es irgendwen interessiert...es gibt ein (nicht grade aktive) Java-Gruppe. Aber vielleicht bringst du ja neuen Schwung hinein.

Maxx

Der Segen wird hier zum Fluch. Mit Java ist es wie mit dem Turm zu Babel. Zu viele verschiedene Frameworks...

Ka, was du hier als Fluch bezeichnest?

Hibernate als Implementierung der offiziellen Java Persistence API (JPA) Schnittstelle?

Spring, das sich als  alsdefakto-Standard für leichtgewicktige (Web-)Entwicklung herauskristallisiert hat?

Einzig in der Präsentationsschicht bin ich auch der Meinung, dass es zu viel Mist gibt. Aber auch da kann man sich einfach an die grossen halten: JSF,struts,wicket...

Problematisch wird es erst, wenn man als nicht vernünftig ausgebildeter Programmierer/Architetekt/... diese Technologien einschätzen soll (unabhängig von einer Programmiersprache). Ich akzeptiere viele Einwürfe, warum eine Sprache nicht für irgendeinen Anwendungszweck geeignet ist. "Es gibt zu viele APIs/Frameworks" gehört nicht dazu. Du must sie ja nicht benutzen...ein "Es gibt keine guten ..." ist etwas anderes, hier aber nicht gegeben. Was ich allerdings akzeptiere wäre z.B. ein "Ich kapiere es einfach nicht", "Ich kann mich nicht in neue APIs einlesen", "Ich erfinde gerne das Rad neu" oder "Die Dokumentation ist schlecht". Wobei hier wohl am ehesten die ersten drei Gründe zutreffen werden.

Maxx

Der Turm von Babel war ein fail, weil es plötzlich so viele Sprachen(Frameworks) gab und ein gemeinsames Arbeiten fast nicht möglich war. 10 Java Entwickler, die gerne ein Browsergame entwickeln würden, und rate mal wieviele verschiedene Frameworks da genannt werden. Der gemeinsame Nenner eliminiert schon eine grosse Anzahl von Entwicklern, die gerne mitmachen würden.

Wenn du von nicht ausgebildeten Hobbyentwicklern sprichst...schon klar das das nicht klappt...

Sprechen wir hier von einem Projekt, das realistischerweise nicht nur über einpaar Monate geht und an dem ausgebildete Informatiker sitzen sehe ich kein Problem sich in ein Framework/eine API einzuarbeiten. Wo liegt da die HErausforderung? Wenn man allerdings eh nicht vorhat mal über den eigenen Tellerrand zu schauen, kann ich die Einstellung wiederum verstehen...laufen ja genügend Raderfinder hier rum...

Maxx

Die gebräuchlichsten Frameworks für Webanwendungen in Java sind wirklich Hibernate und Spring, ich glaub nicht das es da zu großen Streitigkeiten kommt unter professionellen Entwicklern.

Aber zu den Raderfindern :) ... zum Teil muss man halt abwägen, was bietet das Framework und inwieweit erfüllt es die Anforderungen, die man im eigenen Projekt braucht und dementsprechend muss man vielleicht eine andere Lösung finden, das heisst ja nicht, das man dann gleich alle gebräuchlichen Softwarepattern in die Tonne schmeisst.

> ...laufen ja genügend Raderfinder hier rum...

Sagt der, der ein eigenes Forum programmiert hat ;-)

Naja Maxx, eine Sprache in dem sich der Begriff "POJO" (Plain Old Java Object) bildet, zeigt schon, dass in Richtung Frameworks zum Teil ein wenig übertrieben wurde. Aber das schöne an Java ist, man hat ja die freie Wahl.

Wer allerdings neu in die Java Welt kommt, der wird tatsächlich von der Fülle der potentiell einsetzbaren Frameworks erschlagen .

Original von Sarge

Naja Maxx, eine Sprache in dem sich der Begriff "POJO" (Plain Old Java Object) bildet, zeigt schon, dass in Richtung Frameworks zum Teil ein wenig übertrieben wurde. Aber das schöne an Java ist, man hat ja die freie Wahl.

Wer allerdings neu in die Java Welt kommt, der wird tatsächlich von der Fülle der potentiell einsetzbaren Frameworks erschlagen .

Irgendwie habt ihr das noch nie gesehen oder?

package test;
 
import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
 
@Entity
public class Message implements Serializable {
 
 private static final long serialVersionUID = 1L;
 
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
 
 private String message;
 
 
 public Long getId() {
  return id;
 }
 
 public void setId(Long id) {
  this.id = id;
 }
 
 
 public String getMessage() {
  return message;
 }
 
 public void setMessage(String message) {
  this.message = message;
 }

Das ist ein Object mit Annotationen aus der JPA.

Da kann ich nun Hibernate mit verkniffelten, EclipseLink(aka TopLink), Google's App Engine oder was weiss ich was es noch an Persistenz-Frameworks auf dem Markt gibt.

Ach ja ... Undeadable ... Kann C# mittlerweile Nicht-Microsoft-Datenbanksysteme ansprechen?

> Kann C# mittlerweile Nicht-Microsoft-Datenbanksysteme ansprechen

Schon immer. [Korrekterweise aber .Net... C# ist nur eine Programmiersprache]

Mit ADO.Net: Ja (schon immer)

Mit LINQ to SQL: Nein (LINQ to SQL ist aber auch tot)

Mit LINQ to Entities: Ja (Ist auch der 'Standard' O/R-Wrapper... Oder die nächste Sau, die MS durch sein .Net-Dorf jagt)

Ich persönlich setze auf LINQ to Entites für komplexere Dinge und ADO.Net für Trivialitäten.

Original von tkdmatze

Original von Sarge

Irgendwie habt ihr das noch nie gesehen oder?

Doch und das ist nicht mein Punkt gewesen.

Wer allerdings neu in die Java Welt kommt, der wird tatsächlich von der Fülle der potentiell einsetzbaren Frameworks erschlagen .

Schickst du einen Neuling in die Java-Welt wird er von allen Ecken erstmal mind. hören er soll doch bitte Hibernate, Spring, Struts, Tapestry, Coccon, Terracotta, EJB  etc einsetzen damit er ordentlich arbeiten kann. Dann ist er ersteinmal ein halbes Jahr damit beschäftigt die verschiedenen Einsatzzwecke der einzelnen Frameworks herauszufinden und obs für ihn Sinn macht oder nicht. Das sprengt dann schon oft den eigentlichen Projektrahmen den man benötigen würde ohne Frameworks. (Wohlgemerkt als Neuling in der Java-Welt !)

Das und nichts anderes war mein Punkt.

Btw. nicht falsch verstehen, ich mag Java.

Es ist immer das Problem: Was gibts alles, und was davon macht für mich Sinn? Von Trendhopping bin ich nach wie vor kein Freund. Ich entscheide mich für eine Technologie, wenn ich sie gut finde, nicht wenn sie grade In ist und es jeder macht.

Das ist wohl auch einer der Gründe warum es sich "ENTERPRISE" nennt :)

Wie ist das jetzt mit dem Webspace und hosting bezüglich Java+Hibernate+MySQL/PostgreSQL?

Java Webspaces dürftest du inzwischen wohl genug finden, und wenn der Webspace Java hat geht auch Hibernate weil das ist ja selbst auch Java :). MySQL hat sowieso jeder .. bei PostgreSQL weiss ich nicht.

Aber wenn du einen konkreten Hoster genannt haben willst:

InetSolutions - Meiner Meinung nach ein vernünftiger Preis und der Support ist Spitzenklasse.

Um diesem alten Thread mal wiederzubeleben...

Ich schreibe zur Zeit an einem open souce Browserspiel(-framework) in Grails, also Groovy & Java. Grails beinhaltet Spring & Hibernate und vieles mehr und ermöglicht mit relativ kurzer Einarbeitungszeit effektive Webprogrammierung. Gerade die Verbindung der beiden Sprachen ist sehr schön, da man sowohl das stark typisierte Java  wie auch das dynamische Groovy verwenden kann. Wobei ich, solange keine Performance-Gründe dagegen sprechen, mittlerweile wohl immer mehr zu Groovy neigen würde.

Allerdings gilt auch, was für alle Frameworks gilt: je mächtiger es ist, desto härter ist die Landung, wenn tief im Inneren mal ein Balken nachgibt... will sagen, wenn man mit Grails nur einen Bruchteil der Zeit zum Programmieren braucht, die eine simplere Umgebung erfordern würde, dann sollte man sich bewußt sein, daß ein Teil der ersparten Zeit dabei draufgeht, mit dem Framework zu kämpfen. Aber trotzdem: der Einsatz lohnt sich auf jeden Fall.