Architektur-Frage

Hi,

so hab heute meine Prüfung in "Modellierung und Programmierung" erfolgreich bestanden :-)

Beim Lernen gingen mir ein paar Fragen bezüglich der Struktur meines/unseres Browsergames durch den Kopf (war in der Tat nicht dem eigentlich Ziel des Lernens hilfreich  ).

Was ist vorgegeben?

Also direkt vorgegeben ist nichts, aber da wir planen z.B. auch eine Desktop-Anwendung umzusetzten, haben wir uns für ein eher Service-orientiertes Design geeinigt. Sprich auf dem Server gibt es einen Windows-Service der ein Interface sowohl für die eigentliche Webseite als auch für andere Anwendungen bereitstellt. Dort passiert dann die eigentliche ganze Arbeit (Logik und Datenzugriff).

Das ganze wird komplett in .Net umgesetzt, zur Kommunikation mit dem Interface bietet sich daher WCF an. Soweit so gut.

Und die Frage?

Der Rest

Konkreter:

1. Bietet sich dort überhaupt der service-orientierte Weg an oder doch lieber was ganz anderes? Also wie würdet ihr allgemein an so etwas ran gehen.

2. Wie bringe ich da jetzt Objektorientierung rein bzw. macht das überhaupt Sinn? (ich vermute mal die beiden Konzepte schließen sich aus, also eigentlich sinnlose Frage)

Im Moment exisiteren durchaus Objekte, aber die sind nix anderes als Datenhalter (die die Daten noch auf syntaktische Gültigkeit prüfen können, sprich Wertebereich ect.) und diese werden munter über den Service ausgetauscht. Das ist ja nicht wirklich Sinn der Objektorientierung (aber der Serviceorientierung?). Welche Methoden sollte also in einem solchen Fall eine Klasse haben?

3. Allgemein (hat nicht direkt was mit Architektur zu tun): Wie macht ihr das mit Fehlerrückgaben? Dabei meine ich nicht "DivByZero" sondern "Du hast nicht die nötigen Ressourcen". Dabei ist es ja teilweise für den Aufrufer wichtig was schief gegangen ist (Hallo User, wir haben nicht genug Ressourcen! Wir schlagen dir folgenden Deal vor....).

4. Gute Bücher/Webseiten/... über Software-Architektur, am besten mit ein paar Hinweisen, wann was anzuwenden ist. Ich hab da noch nen paar Lücken glaube ich...

Ich denke man merkt dies, aber ich hoffe trotzdem (oder deswegen) auf hilfreiche Beiträge...

1) Warum nicht? Man könnte aber auch versuchen, erst einmal etwas zum laufen zu bringen um das Spieldesign zu testen, bevor man aufwendige Indirektionen einbaut. Wenn das mehr eine technische Studie sein soll und ihr Lust darauf habt, dann macht das. Ansonsten würde ich sagen, baut die Applikation so einfach und flexibel wie möglich auf.
2) Datenobjekte, die ihre eigenen Invarianten sicher stellen sind ein sehr guter Anfang. Das ganze läßt sich dann erweitern. Mit pattern wie dem visitor lassen sich solche Datenobjekte dann um Verhalten erweitern. Welche Methoden eine Klasse haben sollte, hängt von ihren Aufgaben ab. Einfach mal damit anfangen, bestimmten Klassen bestimmte Aufgaben zuzuordnen.
3) Antworten auf Falscheingaben gehören zum ganz normalen Programmfluß. Kann man aber z.B. auch mit einer bestimmten Exception-Klasse abkürzen, der man dann dem Benutzer anzuzeigende Texte mitgibt. Alle sonstige, auftretende Fehler sollte man dann lieber mit "interner Fehler, probieren Sie es bitte später noch mal" quitieren, um keine Hinweise auf evtl. vorhandene Sicherheitslücken zu geben.
4) "Effektive Software-Architekturen", Gernot STarke, Hanser-Verlag; "The Unified Software Development Process", Jaccobson, Booch, Rumbaugh, Addison Wesley
hth Todi

> Das ganze wird komplett in .Net umgesetzt, zur Kommunikation mit dem Interface bietet sich daher WCF an.

Kurz offtopic:

Hast du ein gutes Buch über WCF?

Ansonsten:

Zu 2.: Die Objektorientierung im strengen Sinne: 'Ein Meerschweinchen kann quieken' verliert in dieser losen Kopplung der Elemente immer mehr an Bedeutung. Dort kommt immer mehr ein MVC oder ähnliche Muster zur Anwendung.

Danke für eure Antworten...

@Todi:

(1): Es ist so ein Zwischending zw. einem Experiment und "es soll eigentlich auch was dabei rauskommen"... von daher probieren wir uns immer wieder mit neuen Dingen aus :-)

Diese Struktur mit dem Service usw. haben wir bereits aufgebaut, funz alles ohne Probleme. Jetzt ging es mir um das weitere Vorgehen...sprich wie benutzt man diese Struktur jetzt am besten.

(2): Tja und was haben die Klassen für Aufgaben? Ich meine die normalen Aufgaben z.B. der Klasse Gebäude (Bauen, Abreißen,...) sind bereits im Service vorhanden.

(3): Ich hab mir auch gedacht, dass es normaler Programmfluss ist, und man deswegen eigentlich keine Exceptions verwenden sollte. Und nur eine Meldung wollte ich auch nicht nur zurückgeben, da der Aufrufer wie gesagt auch darauf reagieren können soll... bleibt eigentlich nur etwas in der Richtung Enums zurückzugeben, die dann den Status representieren. Mhhh...

(4): Thx werde ich mir mal ankucken!

@Undead:

Nein ein gutes Buch zu WCF hab ich nicht anzubieten, aber ich finde es gibt sehr gute Internetseiten zu dem Thema (kann ich dir nur leider keine mehr nennen, ist schon etwas her, dass ich mich mit dem Thema intensiv beschäftigt hab). Und eigentlich ists auch ganz einfach :-)

Dann werde ich mich mal mit MVC beschäftigen... wollte mir sowieso mal Asp.net MVC anschauen (sollte sich doch anbieten, oder haben die den Namen nur zur Verwirrung gewählt ).

Nun ja, ich finde diese service-orientierte Sache aber gar nicht so verkehrt. Tatsächlich ist es aber doch so: Sofern du die Ein- und Ausgaben sowohl sauber definiert als auch wie in einenm Model konstruiert hast, arbeitest du "de facto" mit Objekten. Sagen wir mal, du schickst als Antwort (u.a.) einen Knoten User, mit Attributen Name, E-Mail, usw.. was soll das denn sonst sein? Etwa kein konrektes Modell/Objekt? Und idealerweise baust du diese Antwort in deinem Client wieder in ein Objekt um.. voila. Im Umkehrschluss bedeutet das aber auch: Du musst nicht zwingend objektorientiert (wohl aber in gewisser Hinsicht -basiert) arbeiten.. ist doch auch schön.

Wie bereits in einem anderen Thread erst letzte Woche: Die Logik musst du tatsächlich so komplett auf dem Server kapseln, d.h. die Struktur ist so eigentlich kaum noch zu verbessern.

Wenn es für dich bedeutet, dass MVC die Objektorientierung verdrängt --  nun ja, Ansichtssache. Bei deiner Anwendung ist MVC oder ein vergleichbares Muster unabdingbar (wie du ja bereits gemerkt, analysiert und sogar zT implementiert hast). Weil spätestens bei der Remote Execution hast du die 3 Buchstaben entkoppelt...

Was die Exceptions angeht: Bei einem Webservice (in dem Ausmaß) würde spontan(!) zu folgender Idee tendieren: Jede Antwort enthält einen weiteren Baustein, der Meldungen (entweder lokalisiert, oder dein interner Fehlercode) mit entsprechenden Konstruktionsdetails (Ort, Level, Art) beinhaltet. Dieser "messages"-Container kann man natürlich auch auf verschiedenen Ebenen einbinden, dann wird's aber eventuell inkonsistent.

Ob man mit oder ohne Exceptions arbeitet, das liegt daran, ob die Sprache es kann und ob man es will/darf. Ich persönlich finde sie sowohl für erwartete als auch unerwartete Fehlzustände angemessen. Returncodes sind doch voll die Neunziger :D

Original von Todi42

3) [...] dann lieber mit "interner Fehler, probieren Sie es bitte später noch mal" quitieren, um keine Hinweise auf evtl. vorhandene Sicherheitslücken zu geben.

Ich erweitere das gerne zu "Interner Fehler. Fehlercode: abc123" und speichere den Fehler in eine Logdatei. So kann man das bei Folgeproblemen besser zurückverfolgen.