nicht angemeldet
Hallo Nick,
Okay, wir müssen halt Java verwenden. Wie oben schon gesagt, es wird keine Webanwendung. Frank hat gemeint wir sollen gar keine Datenbank verwenden.
Das ist durchaus keine dumme Idee. Object-Relation-Mapping macht meistens Umstände. Wenn man viele Daten hat, kommt man nicht dran vorbei. Bei Euch ist es aber einfacher und vermutlich auch deutliche effizienter, einfach alle Daten für gerade laufende Spiele im Speicher zu halten und beim Unterbrechen eines Spiels irgendwie zu speichern.
Ich könnte mir z.B. so eine Architektur gut vorstellen:
Auf dem Server läuft für jedes Spiel ein Thread. Dieser Thread regelt die Kommunikation zwischen zwei Clients bzw einem Client und einer KI-Instanz.
Gespeichert werden die Daten entweder einfach per Serialization oder falls man das gespeicherte Format auch anderweitig lesen will als XML-Datei oder eben auch in eine Datenbank. Das ist aber Extrafunktionalität. Die Datenobjekte für ein Spiel kann man per Serialization direkt in eine Datei schreiben und später wieder laden.
Client und Server tauschen per RMI direkt Javaobjekte aus. Damit spart man sich auch, ein Protokoll zu entwickeln. Man muss natürlich etwas aufpassen, welche Daten man da hin und her schiebt, und dass der Client nicht Daten bekommt, die er nicht kennen darf (je nach Spiel) oder Daten ändern kann, die er nicht ändern darf. Also nicht einfach das Datenmodell hin und her schicken. Es wäre aber durchaus möglich, den Client über ein Interface direkt Methoden des Datenmodells auf der Serverseite aufrufen zu lassen. Man könnte sogar die Klasse, die die graphische Darstellung eines Spiels erzeugt, auf dem Server ablegen und sie vom Client laden lassen. Dann müsste der Client die Spiele nicht schon kennen und wäre nur so eine Art minimale Laufzeitumgebung. Aber das ist vielleicht etwas zu übertrieben ;-)
Aber ich seh das anderst. Nehmen wir folgendes Beispiel. Es haben sich am Server 7, 8 Spieler angemeldet und spielen. Wird nun eine bestimmte Karte an einen Spieler ausgegeben, genügt ein simples Update...
Wäre ohne Datenbank mindestens genau so einfach. Nur ein Methodenaufruf, die Karte wird in einem Set gespeichert und an den Client geht ein Methodenaufruf receiveCard(Card) o.ä.
Würde man ein Array verwenden, hätte man nicht nur einen höheren Aufwand O(n) - okay bei der Größe wäre der auch so minimal. Aber da irgendwo anzufangen strings oder ids zu vergleichen, ich weiß nicht. Ich halte das nicht für wirklich sinnvoll.
Wenn Du irgendwelche IDs aus Arrays raussuchst, machst Du an der Stelle was falsch. Du musst natürlich ein angemessenes Datenmodell haben und auch mal andere Datenstrukturen als Arrays verwenden (Maps wären für etwas mit IDs vielleicht toll).
Normalerwiese machen Datenbanken die Organisation einer Anwendung wirklich nicht einfacher.
Für Dein welcher User hat welche Karten problem würde man sowas machen:
Map<User, Map<Karte, Integer>> kartenverteilung = new HashMap<User, Map<Karte, Integer>>();
Map<Karte, Integer> stapel = new Map<Karte, Integer>();
boolean gibKarteAn(Karte karte, User user) {
int count = notNull(stapel.get(karte));
if (count == 0) {
return false;
}
stapel.put(karte, count - 1);
kartenverteilung.get(user).put(karte, notNull(kartenverteilung.get(user).get(karte)) + 1);
return true;
}
int notNull(Integer i) {
return i == null ? 0 : i;
}
Mit weniger Logik kommt man da in SQL auch nicht durch. Manche Berechnungen sind in SQL sicher einfacher, weil man eine mächtige Abfragesprache hat. Allerdings ist die Organisation des Programms meist schwieriger, weil man die Logik nicht so geschickt über seine Objekte verteilen kann. Last but not least: So lang Du die Daten so einfach im Speicher halten kannst, ist die Datenbank mit Sicherheit langsamer ;-)
Ich will Dir die Datenbank nicht grundsätzlich ausreden. Aber die eigentliche Anwendungslogik in SQL zu basteln, dürfte Probleme mit sich bringen. Vor allen Dingen, da ihr ja auf andere Spiele erweiterbar sein sollt und das DB-Design damit auch nicht so einfach wird, oder geht es nur um Kartenspiele?
Grüße
Daniel