Mit einem Event liest du nicht zyklisch sondern event getriggert.
Sobald du die SerialPort Instanz mit einem seriellen Port verbindest lauscht dieser auf eingehenden Datenverkehr.
Zyklisch wäre, wenn du immer versuchst einen char zu lesen, allerdings ist dann der zyklus nicht zeitbasiert sondern ebenfalls eventbasiert.
Im Endeffekt ist das SerialPort.Read() also nur ein ausprogrammieren des Eventgetriebenen Ansatzes.
Eine serielle Schnittstelle ist kein Bus sondern eine P2P Verbindung. Einzig allein, wenn du darauf liest erzeugst du keine Last auf dem angeschlossenen zweiten Teilnehmer.
Die SerialPort Klasse von .NET ist dabei ein Wrapper um das Serielle Interface und bietet dir zwei Möglichkeiten Daten zu lesen:
-> Ein Event wird ausgelöst, wenn ein neuer Char anliegt
-> Eine Blockierende Methode, die bis zu einem bestimmten Punkt lesen kann (z.B. 1 Char, EOF, EOL)
Was du davon verwendest liegt an dir, aber wenn du nur einmal kurz liest, nachdem du ein Steuerzeichen/-kommando auf die Verbindung gelegt hast, beachtest du nicht die Verarbeitungszeit auf deinem µC und auch nicht die Übertragungszeigt.
P.S.: Der Artikel mit der drei Schichten Architektur bezog sich darauf, dass du den Klick als auslöser genommen hast um auf der Schnittstelle zu schreiben. Die Datenkommunikationssicht deiner Anwendung sollte nichts von einem Klick wissen, sondern lediglich, dass sie jetzt Daten abrufen soll.
das klingt als würdest du nur einmalig, direkt nach dem Button Klick die Daten lesen?
Generell würde ich das lesen der Daten in den Hintergrund auslagern. Dafür müsstest du allerdings erkennen, wann der µC fertig geschrieben hat - ausser du kannst davon ausgehen, dass wann immer etwas gesendet wird, du es in die Textbox schreiben kannst.
Ich würde dir empfehlen dir die Drei-Schichten-Architektur anzuschauen, dann wärst du vermutlich gar nicht in diese Lage gekommen: [Artikel] Drei-Schichten-Architektur
Kannst du einen Updater Prozess nicht als Hintergrundservice installieren?
Dann könnte der schreibende Rechte auf den Ordner bekommen und dort die Programme updaten ohne dass ein Benutzereingriff notwendig ist.
Soll eine manuelle Aktualisierung notwendig sein, so müsstest du eine Interaktionsschnittstelle schreiben. Aber das ist kein hexenwerk.
So funktioniert das "Ich will was installieren" Programm bei uns auf Arbeit auch und sorgt dafür, dass Programme richtig installiert werden können ohne das Adminrechte der Nutzer notwendig sind.
Nichts für ungut, aber das was ihr mit partial macht ist nur ein verschlimmbessern des Codes.
Partial sorgt ja im Endeffekt nur dafür, dass der Compiler "den Code vor dem Kompilieren zusammenkopiert".
Im Sinne von OOP wäre hier ein Entwurfsmuster anzuwenden, dass dieses Problem löst und eine saubere Trennung erzeugt. Für WPF wäre das MVVM, mit Xamarin habe ich selber noch nichts gemacht, aber XAML weist an sich schon auf MVVM hin. Entsprechend sollte es ein ViewModel geben, welches den Fortschritt als Property bereitstellt und ein Command im ViewModel zum starten der Hintergrundaktion.
Code Behind Spielereien werden sehr schnell zu komplex (und nichts anderes macht partial ja) um sie zu handhaben.
Ich fürchte, dass das mit einem Button und einem einfachen Binding nicht gehen wird.
Entweder du würdest für jede Zelle einen eigenen Togglebutton anlegen, der den Zustand speichern kann und auf den dein Binding geht oder du erstellst ein eigenes Control, dass verwendet wird um die Zelle darzustellen, welches über eine IsItalic und IsBold DependecyProperty verfügt.
Dein Regex kann beliebig komplex werden - vor allem dann, wenn zusätzliche Felder dazu kommen.
Du müsstest es ja nicht zu objekten Deserialisieren, aber du könntest es als Json einlesen und navigieren: https://www.newtonsoft.com/json/help/html/ReadingWritingJSON.htm
Es gibt auch Möglichkeiten ähnlich zu XPATH (da fällt mir allerdings der Name nicht ein - Google wird da helfen).
Ich lehne mich mal weit aus dem Fenster... aber sagt der CLOUD Act nicht aus, dass Regelungen hierfür mit den entsprechenden Ländern getroffen werden müssen? Mir ist das so in Erinnerung, weil der herausgebende Anbieter ansonsten gegen geltendes Recht in den Ländern verstoßen würde, in denen die RZ's betrieben werden.
Der Heise Artikel ist leicht unter aller Kanone. Als extrakt kann man sagen, dass Microsoft eine virtuelle IP im routbaren Bereich, die in jedem RZ genutzt wird und zu der Daten fließen.
--> Was der Artikel nicht direkt sagt ist, dass man nicht nachvollziehen kann ob diese IP in den USA liegt oder doch nur zwei Schränke neben meiner VM. Da muss man den Verträgen und Zertifikaten vertrauen. Das muss man aber sowieso.
Dass Daten fließen ist logisch, denn jeder Virtualisierer nutzt Agents auf den Maschinen um diese über die virtuelle Hardware hinaus zu überwachen und Kommandos (wie z.B. Fahre herunter) zu senden.
Dass diese IP in jedem RZ gleich ist spart Konfigurationsaufwand und Pflegeaufwand für die Images (wobei man das sicher automatisieren könnte oder z.B. über eine DNS Auflösung lösen könnte).
DSGVO betrifft (nach meinem Kenntnisstand) Hauptsächlich Personenbezogene Daten. Hierzu werden die Daten, die in einem Serversystem anfallen, welches gerade Provisioniert wurde sicherlich nicht gehören (ausser eventuell dem gewählten Administrator Benutzernamen).
Ich würde eine Prüfsumme mit auf den Beleg bringen, die nur du in dieser Form erstellen kannst. Damit kannst du prüfen ob tatsächlich du (bzw. das Unternehmen) diesen Beleg erstellt hat. Dabei muss der Betrag ebenfalls mit in die Prüfsumme hinein.
Das würde dann einer Signatur entsprechen. Was ich auf keinen Fall machen würde, wäre einen Fancy-Prüfsummen Algorithmus selber entwickeln, sondern eine Zertifikatsbasierte Signatur nutzen.
Wenn ich das richtig verstehe, weißt du beim Abruf der Daten von der API nicht, was zurückkommt?
In dem Fall könntest du mithilfe von eigenen Convertern und Newtonsoft.Json arbeiten, das Format erkennen und das richtig Objekt erstellen.
Wenn du weißt, wie die Struktur aussieht erstelle dir selber oder mithilfe eines von vielen online verfügbaren Generatoren aus dem Json eine (bzw. mehrere) Klasse(n) und lass den string zu Objekten von diesen deserialisieren.
Steht dir auch das Azure AD zur Verfügung?
Falls ja würde ich über OIDC gehen und vielleicht sogar die Accountverwaltung durch IdentityServer4 machen lassen, da bekommst du das schon fertig und musst dich in deiner Anwendung nicht mehr darum kümmern.
Vom Prinzip ja.
Du kannst die API Beschreibung (ähnlich wie das wsdl) auch vom Server dynamisch generieren lassen und dann deinen Client Code daraus generieren. Ist - finde ich - einfacher, als die DTO's in einer Shared Lib zu halten.
Wenn dein Client ausschließlich auf Windows läuft - was spräche dagegen den initialen "Dominostein" von Windows sichern zu lassen?
Windows bietet dazu eine API, in der auch z.B. IE die Zugangsdaten für Webseiten speichert (ob es bei Edge noch genau so ist weiß ich allerdings nicht) und diese wären mit den Benutzerkonto* abgesichert.
* Allerdings dem lokalen Benutzerkonto, nicht mit dem Active Directory Konto. Bei einem Rechnerwechsel müsste also irgendwie einmalig dieser Schlüssel wieder eingegeben werden.
Es gibt auch für RESTful API's eine gemeinsame Beschreibungssprache, das OpenAPI Format.
Für .NET und ASP.NET (inkl. Core) gibt es sogar mehrere Toolings, z.B. NSwag.
Prinzipiell eignet sich dafür jedes Dateiformat. Die Frage ist ob es sinnvoll ist soetwas zu machen - die würde ich dir selber überlassen.
Im Endeffekt bildet die Konfigurationsdatei, egal ob xml, json oder ini nur eine Objektstruktur (also Instanzen von Klassen) ab, die du zur Laufzeit mit Werten aus der Datei (= Deserialisierung) befüllst und dann auswertest.
Das gleiche würde auch mit einer Datenbank oder einer anderen Abstraktion (z.B. HTTP REST API) funktionieren.
Ini Dateien bieten dir dabei allerdings lange nicht die Flexibilität und Unterstützung durch Bibliotheken, wie xml oder json. Sie haben gefühlt auch eher den Touch der 90er Jahre :)
Abgesehen von den Empfehlungen der anderen hier ist das Problem, dem di gegenüberstehst genau der gleiche grund, warum du eine Abstraktionsschicht zwischen App und DB verwenden solltest:
PHPMyAdmin ist eine solche Abstraktion. Als Webseite läuft das backend - dass mit der Datenbank kommuniziert - auf deiner NAS. Deswegen benötigt es auch Zugriff von 127.0.0.1, nicht von extern.
Dein benutzer scheint so angelegt zu sein, dass er nur von localhost zugreifen darf.
Docker kann für dich eine Serverseite einer WebApp sein.
Weder unter .net core, noch unter Mono kannst du WPF nutzen. WinForms nur unter Mono und nur eingeschränkt... allerdings als Client für z.B. eine REST API, die du in Docker haben kannst.
Wenn du etwas Webbasiertes verwenden willst wäre Docker die richtige Wahl. Willst du WinForms nutzen, so kannst du durchaus deine Logik in Docker abbilden musst aber die GUI davon getrennt haben.
danke für deine Geduld mit mir. Ich komme wahrscheinlich einfach aus einer sehr unterschiedlichen Welt der Programmierung und muss mich erst noch an vieles Gewöhnen.
Die Doku zum persistieren der Verbindungen hatte ich mir schon angeschaut - es bleibt mir allerdings noch eine Frage, vielleicht verstehst du dann auch meine ganzen Fragen in der Richtung besser :)
-> Ein Websocket ist ja anders als eine Klassische Webseite (ob SPA mit WebApi, MVC oder irgendwie anders gelagert) eine Stateful Application, durch den logischen Kanal der hier mittels einer aufrechterhaltenen TCP Verbindung herrscht bekommt die App einen Zustand (den Socket in diesem Fall).
Wenn ich jetzt die "Verbindung" persistiere kann deswegen doch eine zweite Instanz nicht auf diesen Zustand zugreifen, denn die Verbindung hat als Inhalt nur Benutzerdefinierte Proerties, aber niemals einen Socket.. diesen kann ich gar nicht auf diese Weise persistieren.
Folgendes Szenario:
Es existierten zwei Instanzen der Websocket App (A, B).
Client baut Verbindung mit Instanz A der Websocket App auf.
Instanz B (hängt an der gleichen Queue des Service Bus) erhält eine Nachricht, die für den mit Instanz A verbundenen Client bestimmt ist, holt sich die "Verbindung" aus dem Storage und dann? Wie kommt die Nachricht in den logischen TCP Kanal? Einfach senden kann die Instanz B ja nicht, das blockiert jede Firewall.
Oder ist das alles soweit standardisiert, dass sich jeder beliebige Reverse Proxy (denn was anderes sind ja Load Balancer nicht) um die Weiterleitung kümmert?
Zitat
PS: was die Authentifizierung mit dem EventProcessor des Event Hub zutun hat, weiß ich leider nicht ;-)
Das bezog sich auf
Zitat
Damit könntest Du den ASP.NET-Part weglassen, wenn Du Cloudnative sein willst.
aber vielleicht fehlen mir dazu die basics, denn der ASP.NET-Part kümmert sich bei mir neben Authentifizierung (über JWT) noch um die Authorisierung.
ich bin kein Experte, was WinForms angeht und auch kein Freund von direktem Datenbankzugriff von Applikationen.. aber das kleingt, als würdest du Databinding betreiben. In dem Fall müsstest du dafür sorgen, dass die Datenquelle deiner Checkbox True wird, anstatt in der GUI das Checked zu setzen.
Der Fehler ist, dass du jedesmal eine neue Instanz von Form1 erstellst.
Lösen könntest du dies über: [FAQ] Kommunikation von 2 Forms
Besser wäre sicherlich eine Dienstklasse, die im Hintergrund den Warenkorb verwaltet. Beide Forms bekommen dann diesen Dienst beim erstellen übergeben (=> Dependency Injection).
Wir schweifen ab :)
Problem ist sicherlich falsch, was fehlt ist ein einfacher Weg zu finden und zu vergleichen. Da ist sicherlich viel Vorarbeit gemacht, aber viel kann auch nur durch Erfahrung beurteilt werden.
Zu der von dir angesprochen Partitionierung finde ich leider kaum etwas in Bezug auf SignalR.
Zitat
Wenn man in Instanzen denkt, dann ist das Scaling Konzept falsch ;-)
Ist es so einfach und ich kann das aussen vor lassen? Würde mir natürlich entgegen kommen, wenn dem so ist.
Der Knoten in meinem Kopf sieht wie folgt aus:
Angenommen ich habe mehrere WebApp Instanzen. Ein Client verbindet sich aber immer nur mit einer davon (richtig? Sonst wäre ja Load Balancing nicht zum verteilen der Clients auf mehrere App Instanzen). Wie ist dann sichergestellt, dass der richtige Client alle Nachrichten bekommt, wenn theoretisch jede App Instanz nur einen Teil der Message Queue Nachrichten bekommt?
danke - das kenne ich. Ist allerdings noch in der Preview. Behebt aber denke ich auch nicht mein Hauptproblem, dass wird ja entsprechend sein, die eingehenden Nachrichten so zu verarbeiten, dass ich sie auf die Gruppen aufteile.
@Abt: ja, das ist finde ich ein Riesenproblem von Azure. Es gibt soviel Auswahl und man kann so viele Dienste nutzen um ähnliche Funktionalitäten zu erreichen.
Da ist es schon praktisch, wenn es die passenden MS Partner Firmen gibt die da aushelfen können.
EventHub habe ich mich noch nicht mit beschäftigt, fällt bei mir aber glaube ich raus, da ich die Authentifizierung über Identityserver mache.
wie stellst du dann sicher, dass z.B. mit Loadbalancing, die richtige Instanz der WebApp die Nachrichten erhält?
Ich arbeite mit Azure ServiceBus und jede Nachricht, die ich in eine Queue hineinwerfe kann von genau einem Client verarbeitet werden (ausser ich werfe sie vom Client aus wieder zurück... dann habe ich aber ein Problem und muss irgendwie bestimmen, dass ich die Nachricht schon einmal verabeitet habe)...