Hmmm, das ein Jahr auch 53 Kalenderwochen haben kann sollte eigentlich bekannt sein - unabhängig vom Programmieren - also weit entfernt von den C# Grundlagen um die es hier geht.
Man muss die Kommentare in zwei Bereiche teilen, denn diese adressieren unterschiedliche Rollen.
Die Kommentare vor der Methode/Eigenschaft (XML-Dokumentation) sind zum großen Teil für diejenigen Entwickler gedacht, die diese Klasse verwenden wollen/sollen.
Da sollte also vermerkt sein, was man von dieser Methode zu erwarten hat und was für Exceptions kommen könnten. Wer sich nicht sicher dabei ist, der schaut sich einfach mal die MSDN Dokumentation an.
Kommentare im Code sind primär für die Entwickler gedacht, die diese Methode implementieren oder überarbeiten. Hier sollte das Ziel sein, so gut wie ohne Kommentare auszukommen. Sprechende Namen (Variablen, Methode, Eigenschaften) helfen dabei ungemein.
Wenn du Wäsche in die Waschmaschine packst, dann brauchst du nicht davor zu warten, bis das Waschprogramm durch ist, denn die kann das alleine. Also asynchron.
Du kannst aber nicht in der gleichen Waschmaschine noch eine Ladung Wäsche waschen lassen. Also nicht parallel (dazu bräuchtest du mehrere Waschmaschinen).
Das was du da machst (asynchrone Aufrufe parallel ausführen) ist nicht immer zulässig.
Ist das so empfehlenswert, oder sollte ich dies anders umsetzen?
Setze es anders um => mit async/await und einem Timer.
Zitat von "IncepTer"
Also dachte ich mir, ich baue eine Methode zum stoppen, welche von dem neuen Windows Form aufgerufen wird:
...
Danach sollten dann die Werte in die DB gespeichert und der Thread neu gestartet werden.
Nö, wieso ... wenn du den Wert direkt da hast, dann trag den in das Label ein, ansonsten frag die Datenbank eben direkt danach ab (bzw. frag den Service).
Wenn du unbedingt abbrechen (pausieren) möchtest, dann ist das mit dem Timer (s.o.) wesentlich einfacher zu lösen.
Was für ein Problem mit diesem Session-Objekt gelöst werden soll ist mir schleierhaft.
Eine Unterhaltung kann doch zwischen 2 (eigentlich auch 1) bis n Benutzern stattfinden. Die Unterhaltung selber ist technisch nicht anders, wenn diese zwischen 2 oder n Benutzern stattfindet.
Also, wen haben wir da im Boot?
die Unterhaltung
die Teilnehmer
die Nachrichten
Die Nachricht wird von einem Teilnehmer erstellt und an die Unterhaltung geschickt. Der Server weiß, ob der Absender Teilnehmer der Unterhaltung ist (oder eben nicht) und fügt die Nachricht der Unterhaltung hinzu (oder eben nicht).
Vom Grundprinzip her also relativ simpel ohne viel Tamtam.
Dann solltest du aber darauf achten, was du wirklich testen möchtest.
Wenn deine Test-WebAPI die Daten annimmt, konvertiert und in die Datenbank einträgt, dann misst du nicht nur die Übertragung.
Wenn es auf den Durchsatz ankommt, dann kann die WebAPI die Daten auch entgegennehmen und in eine Queue eintragen (MSMQ, RabbitMQ, etc.). Von dort aus können dann n Systeme diese Daten verarbeiten.
Visual Studio 2017 => v15.x
Visual Studio 2015 => v14.x
Von welchem Visual Studio Versionen sprichst du jetzt, wenn du VS17 / VS15 schreibst?
Ich vermute mal VS17 => VS2017 und VS15 => VS2015, denn die Version 17 gibt es wohl noch nicht (und wenn, dann als ganz frühe alpha)
Ich würde jetzt mal sagen, das Problem hat gar nichts mit REST & Co. zu tun.
Die Parameter müssen für die Signierung kodiert werden, was AmzLibrary.GetParametersAsString auch macht.
Der RestClient kodiert diese Parameter für den Request allerdings auch und genau da würde ich sagen liegt das Problem. Ein Leerzeichen kann als + oder als %20 kodiert werden. Der Sinn ist der gleiche. Für die Signierung ist das aber eben nicht das Gleiche.
vor dem Schreiben kommt das Lesen (von Dokumentationen oder hier im Forum die Antworten). Dieses Lesen sollte vollständig und mit der nötigen Ruhe erfolgen, sonst wird das nichts mit dem Programmieren.
Und wenn ich sowas umsetzen müsste, dann würde es für mich nur Produkte geben.
Dazu noch Templates für neue Produkte (wie z.B. Auto-Template, Motorrad-Template, Kettensägen-Template ...) um nicht bei jedem bei Null anfangen zu müssen.
Du willst jetzt also ernsthaft für jedes Produkt eine eigene Klasse definieren?
Wie muss ich mir das dann in der Produktiv-Umgebung vorstellen, wenn ein neues Produkt erstellt werden soll? Soll das dann Aufgabe der Entwicklungsabteilung sein (Anwendung erweitern, Testen, Rollout)?
Selbst wenn man EF ausser acht lässt, sieht man, dass das Konzept schon im Ansatz nicht richtig sein kann.
Grundsätzlich sollte man sich von dem Gedanken verabschieden eine Datenbank-Oberfläche zu erstellen, denn genau daher kommt die Denkweise, dass sich alles um diese Datenbank dreht.