Design-Frage: Klasse mit "ablaufenden" Werten

  • Allgemein

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von ery.

    Design-Frage: Klasse mit "ablaufenden" Werten

    Neu

    Hallo!

    Ich habe eine Anwendung (Client-seitig) entwickelt welche sich per oAuth2 und PKCE authentifiziert. Da dies der größte bzw. schwierigste Teil (für mich - immer noch Anfänger) meiner Anwendung war und ich gerne anderen Personen das abnehmen möchte würde ich gerne eine .NET Library (dll) erstellen welche das übernimmt. Das möchte ich, für den jeweiligen User (Entwickler) so einfach wie möglich halten.
    • Einbinden der DLL
    • Übergeben der benötigten Werte um die Auth durchzuführen
    • Der User kann dann mit den (sich in der Klasse ändernden) Werten arbeiten ohne sich selbst um Werte mit einem zeitlichen Ablaufdatum zu kümmern
    Leider weiß ich nicht wie ich das aufbauen soll.
    Kann ich, nachdem ich die Daten in die DLL übergeben habe, diese dann in sich selbst automatisch per Timer aktualisieren lassen (Refresh-Token und Access-Token werden in der Klasse regelmäßig neu abgefragt, der Timer stellt das sicher, wenn das klappt(?)) und der User greift dann darauf per klasse.wert1 und klasse.wert2 zu, wenn er die Anfrage auf den jeweiligen Scope machen möchte? Kann ich so etwas wie IntelliSense zur Verfügung stellen? Muss ich beim Klassendesign etwas beachten?..

    Danke!

    Neu

    @ery Das mit der DLL geht folgendermaßen (reines DLL-Handling, Deine Spezial-Probleme behandle ich jetzt nicht):
    Füge Deiner Projektmappe ein DLL-Projekt hinzu.
    Füge Deinem Hauptprojekt das DLL-Projekt, nicht aber die DLL-Datei, als Verweis hinzu.
    Gib dem DLL-Projekt in der Release den Haken XML-Dokumentationsdatei erstellen.
    Du bekommst dann Compiler-Warnungen, wenn Kommentare fehlen (''' über der Funktion eingeben und den Rest ausfüllen).
    Die entstandene XML-Datei verteilst Du dann mit Deiner DLL, sie beinhaltet die IntelliSense-Information.
    ====
    Du musst wissen, ob der Timer in der DLL synchron als GUI-Timer (im GUI-Thread)
    oder
    asynchron als Threading.Timer laufen soll.
    Im ersten Fall kannst Du Daten direkt an der GUI anzeigen,
    im zweiten Fall musst Du aus dem Timer-Thread in den GUI-Thread invoken.
    Dann wäre es ggf. sinnvoll, dass der DLL-Thread selbständig das Hauptprogramm per Event benachrichtigt, wenn sich Änderungen ergeben, die GUI muss da nicht permanent nachfragen.
    Wenn Du eine Pizza bestellst, rennst Du auch nicht alle 30 Sekunden zur Tür und siehst nach, ob der Bote da ist, sondern Du wartest darauf, dass er klingelt.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Vielen Dank für die Antwort. Ersterer habe ich verstanden, sollte wohl nicht allzu schwer sein!

    Beim zweiten habe ich jedoch ein Verständnisvproblem. Ich warte meist direkt an der Tür da ich schon so Lust auf die Pizza habe!
    Aber im Ernst: Da der Code nach einer bestimmten Zeit komplett abläuft und ich den, solange die Anwendung läuft, immer aktualisieren möchte hätte ich schon an einen komplett eigenständigen, ständig laufenden Timer gedacht.
    Macht das keinen Sinn? Eben damit der Benutzer der DLL nichts mehr machen muss außer auf die freigegebenen Variablen zuzugreifen. Wäre vermutlich ein Threading.Timer. Aber warum muss ich hier einen Timer in den GUI-Thread invoken? (Der Timer hat dann ja nichts mit dem GUI-Thread zu tun?).
    Und für ein Event müsste der User dann auch wieder selbst etwas beachten

    Neu

    ery schrieb:

    ständig laufenden Timer
    Klar.
    Nun kann dieser Timer in der GUI oder in der DLL laufen.
    Was meinst Du mit
    freigegebenen Variablen
    Wenn in der DLL was fertig ist, sendet sie ein Event.
    Dies kann einmal ein "Weckruf" sein, dass das Hauptprogramm Daten in der DLL abholt
    oder
    es ist ein Event, dem die Daten in den speziellen EventArgs mitgegeben werden.
    Vielleicht beschreibst Du mal etwas näher, was da abläuft.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Okay. Der Plan wäre das der Timer in der DLL läuft, sobald ein "Tick" Event auftritt werden die Access und Refresh-Token neu generiert und sollen dem Entwickler, welcher mit der DLL arbeitet, die fertigen Werte liefern (also die ganze oAuth2 und PKCE Generierung ist schön ausgelagert und mit so wenig Aufwand wie möglich zu bedienen sein).

    Diese Werte meinte ich mit "freigegebenen Variablen", also z.B. nur noch in seinem Abruf die Daten meiner DLL verwenden muss ohne sich selbst über dessen Generierung Sorgen zu müssen. Zum Beispiel sendet er dann selbst nur noch einen POST-Request an den Server (hat jetzt nichts mit meiner DLL zu tun) und im Header (dort, wo der Access-Token benötigt wird) steht sowas wie 'MyClass.access_token' - diese Daten generiere ich in der DLL.
    Der Entwickler muss in seinem Tool ständig, zu unterschiedlichen Zeiten, auf diese Codes zugreifen - diese Codes sind 20 Minuten gültig. Im Hintergrund würde ich mich selbst gerne um die zeitgerechte Abwicklung - z.B. alle 15min - kümmern.

    Neu

    Danke, schau ich mir dann am Abend durch!
    Ja, ich veröffentliche alles OpenSource - der Einfachkeit halber möchte ich aber trotzdem eine DLL bereitstellen die viele Arbeiten übernimmt. Wenn man mag kann man die ja noch immer selbst kompilieren :)