Whiz-zarD

Web-Applikationen sind auch nicht mehr das "Nonplusultra". Der Trend geht in Richtung Mobile-First. D.h. es wird zuerst eine Mobile-App entwickelt, bevor man eine Web-App entwickelt. PHP- und ASP.NET-Anwendungen sind auch schon auf dem Rückzug. Sie werden uns zwar noch viele Jahre begleiten aber der Trend in Web-Apps geht in Richtung sog. Single-Page-Applikationen (SPA). SPAs haben den Vorteil, dass der Server entlastet wird, indem das Rendering auf dem Client stattfindet. D.h. der Server schickt nur noch die rohen Daten zum Client (Browser) und der Browser bastelt daraus selbst das HTML-Dokument. Für SPAs braucht man auch keinen dicken Webserver ala Apache, sondern es reicht auch was leichtgewichtiges, was die Anfragen annimmt und jemandem damit beauftragt. In der .NET-Welt gibt es z.B. NancyFx, was einen HTTP-Request annimmt und verarbeiten kann. NancyFx ist angelehnt an das Ruby-Projekt Sinatra. NancyFx könnte also z.B. ein HTTP-Request entgegennehmen und es an einen Microservice weiterleiten und das Ergebnis zurück zum Client schicken. Auf dem Client läuft dann ein Framework ala AngularJS oder React, mit denen dann die HTML-Dokumente erstellt werden. Klassische WinForms Anwendungen gibt es zwar noch in der Business-Welt aber die sind eher historisch begründet. Wir entwickeln auch noch eine aber wir haben mit der Planung der nächsten Generation angefangen und die deutliche Mehrheit unserer Kunden (Banken) wollen keine Desktop-Applikation, weil sie damit einen höheren Aufwand haben, da sie virtuelle Desktops bereitstellen müssen. Auch der Trend bei unseren Kunden geht also hin zu mobilen Endgeräten. Also nein, auf Desktop-Anwendungen würde ich heutzutage nicht mehr setzen, es sei denn, du hast da was sehr spezielles, was in einem Browser nicht funktioniert oder vom Vorteil wäre, wenn es auf einem Desktop läuft aber selbst bei 3D-Grafiken ist WebGL da schon sehr weit. Man muss auch berücksichtigen, dass selbst bei Ottonormalverbrauchern der Trend in Richtung Mobile-Geräten geht und da sollte man sich schon fragen, ob es Klug ist, eine sehr große Klientel auszugrenzen.

Er ist über 30. Mit Sicherheit geht er nicht mehr zur Schule...

Ich sehe das ähnlich, wie @Gottlike. Dein Kenntnisstand ist noch nicht so weit, um so ein Projekt anzugehen. Ich will nicht zu Nahe treten aber dir ist OOP offenbar immer noch nicht so wirklich klar. Das fängt schon, wie gesagt, mit der statischen Klasse für den Spieler an. Wieso soll sie statisch sein? Das macht überhaupt keinen Sinn. Statische Klassen machen nur in wenigen Situationen wirklich Sinn. In der Praxis werden sie aber oft dann verwendet, wenn der Entwickler gar nicht weiß, was er eigentlich tut. Das nächste ist, dass dir gar nicht klar ist, wie man Programmlogik von der Oberfläche trennt. Die Main-Methode einer klassichen WinForms-Anwendung besteht lediglich nur aus drei Zeilen Code: static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } Was du noch in die Main()-Methode reinkloppen willst, erschließt sich mir erst mal nicht. Ein erfahrener Entwickler wird mit Sicherheit diese Methode noch erweitern, z.B. mit der Initialisierung eines IoC-Containers oder sonstigen Frameworks aber das sind Techniken, mit denen du mit deinem Wissensstand noch nichts anfangen kannst. Ich vermute auch mal, dass dir die ganzen Designpatterns nichts sagen. Wenn man dein Beitrag auch durchliest, machst du dir viel mehr Gedanken, um die Oberfläche, anstatt um die Architektur der Software, daher ist das Ziel noch viel zu hochgesteckt. Fange mit Konsolenanwendungen an, um überhaupt OOP zu verstehen und um ein Gefühl dafür zu bekommen. Eine Oberfläche ist eigentlich nur ein schmuckes Beiwerk für eine Software. Ich persönlich würde vielleicht vorschlagen, eine API für Schach zu entwerfen. Ohne Oberfläche. Also überlegen, welche Datenstruktur ein Schachbrett und die Figuren haben könnten und dann noch Logiken, die ermitteln, welche Figur welchen Zug machen kann. Testen kann man das Ganze ja auch mit Unittests. Eine grafische Oberfläche muss ja nicht immer eine gute Note bedeuten aber keine Ahnung, ob das nicht schon zu schwer ist. Eine einfachere Form wäre Dame oder noch einfacher: Tic-Tac-Toe.

Sofern Microsoft nicht die Schnittstellen ändert und ältere Clients die neue Schnittstelle nicht implementiert haben...

Okay. Schade. Trotzdem danke.

Genau

Nur irgendwie nervt es. Auch eine Frage wird schnell zu einem Thread, da dort dann weitere Fragen gestellt werden und dann wird es schnell unübersichtlich, was nun die neueste Antwort bzw. Frage ist. Jedes Mal muss man den "Nach Datum sortieren"-Button klicken, um den chronologischen Verlauf zu verstehen.

Kann man irgendwo angeben, dass das Forum die Posts nach standardmäßig Datum sortieren soll und nicht nach Bewertung? Das macht mich immer ganz wahnsinnig.

Bei Onlinespielen der Spieleserver.

Du brauchst du dafür gar nichts. Du musst wissen, wie man zwischen zwei Rechnern Nachrichten verschickt (z.B. über TCP und UDP). Wofür brauchst du denn da eine Datenbank? Nicht nur auf Windows ... Wenn ein Router dazwischen hängt, musst du das Portforwarding aktivieren, damit auch die Datenpakete zum lauschenden Rechner weitergeleitet werden. Um das zu umgehen, verwenden Onlinespiele oder Messengerdienste die Hole Punching-Technik. Darüber würde ich mir aber erstmal keine Gedanken machen.

Ein Datenbank-Server sollte nie direkt von Außen ansprechbar sein. Wenn, dann über ein VPN oder über ein geeignetes Administrationstool, was auf dem Server liegt (z.B. phpMyAdmin) und vor fremden Zugriff abgesichert ist. Ob du eine Datenbank für ein Multiplayer-Spiel brauchst, liegt auch am Spiel selbst. z.B. Minecraft kommt auch ohne Datenbank aus. Datenbanken sind nicht immer das Allheilmittel. Ich würde auch kleinere Brötchen backen, bevor ich mich da an ein Multiplayer-Spiel ranwagen würde. Fange erstmal klein an. z.B. Tic-Tac-Toe und arbeite dich an größere Dinge. Selbst die Implementierung von Schach kann schon sehr kompliziert werden.

Keiner wird für dich deine Hausaufgaben machen. Bitte erläutere, wo deine Schwierigkeiten liegen.

IRC ist das einzig wahre

Das habe ich auch gedacht und da sehe ich die größten Probleme. In der Doku wird einfach lapidar behauptet, dass in der Konfigurationsdatei Host, Port, Nutzer, Passwort und Datenbankname eingetragen wird aber wie steht es mit der Sicherheit des Passwortes? Steht das Passwort in Klartext in der Datei? Das selbe gilt dann auch für die User-Tabelle. Wird das Passwort verschlüsselt abgelegt? Wenn ja, wie? Es sieht auch so aus, als könnte man Benutzer gar nicht sperren. Auch sowas wie Anzahl Login-Versuche und das Datum des letzten Erfolgreichen Logins wird nicht gespeichert. Das sind aber essentielle Dinge, um mögliche Angriffe zu identifizieren. Es fehlt auch das technische Know-How in der Doku. Also warum es so umgesetzt wurde, wie es umgesetzt wurde. Die Schwierigkeiten und Herausforderungen werden nicht deutlich. Technische Dinge, wie z.B. die Grafik mit der PGP-Verschlüsselung stammen 1:1 aus Wikipedia und es wird nicht mal näher darauf eingegangen. Man nimmt es also einfach so hin, ohne es zu reflektieren. Es wird nicht mal erwähnt, wie die Zwei-Faktor-Authentifizierung nun abläuft. Bekommt der Benutzer eine Mail?

Davon gehe ich dann auch mal sehr stark davon aus. Ein Prüfer hat davon auch nichts, wenn er einen Azubi absichtlich durchfallen lässt. Ich weiß nicht, wie es bei anderen aussieht aber bei mir haben zwei Prüfer die Dokumentation angeschaut und wenn die Bewertung weit auseinander liegt, wurde ein dritter Prüfer einberufen.

Du musst die XML-Datei einlesen und durch die Elemente iterieren und die, die du umgewandelt haben möchtest, mit der WebUtility.HtmlEncode()-Methode umwandeln und zum Schluss die XML-Datei neu speichern.

Ich weiß auch nicht, warum man hier jetzt noch nachtreten muss.

Das sind leider alle Informationen, die ich gerade finden kann. Die Information stammt aus diesem Buch.

Ich bin mir da jetzt nicht ganz sicher, ob .NET 4.6 abwärtskompatibel zu 4.5.1 ist. Es genügt aber auf den Maschinen, wo 4.6 läuft 4.5.1 zu installieren. Du brauchst es nicht deinstallieren. Nicht unbedingt. Es gab in der Vergangenheit schon breaking Chances, die dafür sorgten, dass .NET nicht abwärtskompatibel war.

XML-Dateien sollten nicht mit regulären Ausdrücken geparsed werden: https://stackoverflow.com/questions/6751105/why-its-not-possible-to-use-regex-to-parse-html-xml-a-formal-explanation-in-la Du merkst ja selber, dass es gar nicht so trivial ist, da du z.B. auch Zeilenumbrüche berücksichtigen müsstest. Das beste ist, du lässt die XML-Datei mittels einer geeigneten Bibliothek (mit welcher Sprache entwickelst du?) und löschst dann die Einträge aus der DOM-Struktur und generierst eine neue XML-Datei.

Ich muss gestehen, dass ich mit Hibernate direkt noch nicht gearbeitet habe, sondern mit dem .Net-Ableger NHibernate. Dort gibt man in der SessionFactory den Connectionstring mit. Der kann ja dynamisch erzeugt worden sein. Du kannst bei Hibernate auch die Konfiguration überschreiben: http://stackoverflow.com/questions/18033288/programmatically-configure-hibernate-with-dynamic-username-and-password Wie das jetzt unter Java implementiert wird, weiß ich nicht. Das letzte Mal, als ich mit Java entwickelt habe, ist schon einige Jahre her. Ich entwickle hauptsächlich mit C#. Wir haben es so gelöst, wenn das FormClosed-Event vom Hauptfenster ausgeführt wird, schließen wir die Verbindung. Also ja, ein shutdown Hook.

Wo ist denn das Problem, den Nutzer die Möglichkeit zu schaffen, Benutzername, Passwort, Server, Port, etc. über die Anwendung anzugeben anstatt die Werte statisch im Code zu schreiben? Du erzeugst einfach eine Singleton-Klasse, die die Konfiguration speichert. Mit Hilfe des Singletons kannst du eine Datenbank-Verbindung aufbauen, die du dann in dein Controller reichst. In diesem Zusammenhang schaue dir mal Hibernate ORM an. Das ist ein Object/Relational-Mapper (O/R-Mapper). O/R-Mapper haben die Aufgabe, Relationale Daten, wie sie in einer relationalen Datenbank stehen, in Objekte, gemäß der Objektorientierung, zu wandeln. O/R-Mapper kapseln schon deine Geschäftslogik von der Datenzugriffsschicht ab, sodass du in der Geschäftslogik gar nicht weißt, woher die Daten stammen.

Eine CSS-Datei benötigt keine verbundene Spalten. Die CSS ist nur für die grafische Darstellung der Spalten da. Der Fehler liegt also im HTML-Dokument, da eben nicht genügend Spalten verbunden werden, damit die Spalte bis zum Ende geht und nicht nach der achten aufhört.

Das Problem ist doch, dass 8 Spalten verbunden werden und nicht 10 und anstatt den Fehler zu korrigieren, soll er ausgeblendet werden? Spricht nicht gerade für den Betrieb ...

Ich versteh nicht, wo genau dein Problem ist. Kannst du es vielleicht mal anhand eines Beispiels erläutern?