Grundlagen

Modul eins. Ihre erste Wisej.NET-Anwendung. Wir erstellen einen kleinen Bildschirm, der nach einem Namen fragt und eine Begrüßung anzeigt. Dies stellt den grundlegenden Arbeitsablauf vor: Entwerfen der Benutzeroberfläche, Behandeln eines Ereignisses und Testen des Ergebnisses in einem Browser.

Beginnen Sie in Visual Studio und wählen Sie „Neues Projekt erstellen“. Wisej.NET nutzt den bekannten Projektworkflow mit Vorlagen, die die ersten Anwendungsdateien bereitstellen. Die Schnittstelle wird im Browser ausgeführt, während unser Ereigniscode auf dem Server ausgeführt wird.

Suchen Sie nach Wisej.NET. In dieser exemplarischen Vorgehensweise wird die Webanwendungsvorlage Wisej.NET 4 mit C# verwendet. Wählen Sie diese Vorlage aus und fahren Sie fort. Wenn es in Ihrer eigenen Installation fehlt, überprüfen Sie, ob die Erweiterung Wisej.NET und die Projektvorlagen installiert sind, bevor Sie fortfahren.

Wählen Sie einen Projektnamen und einen Speicherort und klicken Sie dann auf Erstellen. Visual Studio generiert das Projekt und sein Startfenster. Schauen Sie sich Solution Explorer an: Hier finden Sie die Anwendungsdateien und kehren zum Fenster zurück, während Sie den Bildschirm erstellen.

Erstellen Sie das Projekt, bevor Sie den Designer öffnen. Der Build kompiliert die Anwendung, sodass der Designer ihre Typen laden kann. Beobachten Sie das Ausgabefenster und warten Sie, bis der Build erfolgreich war. Wenn der Build fehlschlägt, beheben Sie die Fehler, bevor Sie mit dem Layout fortfahren.

Doppelklicken Sie in Solution Explorer auf Window1, um die Entwurfsansicht zu öffnen. Dies ist die Oberfläche, auf der wir die Steuerelemente anordnen. Der Designer zeichnet sein Layout in Window1.Designer.cs auf. Behalten Sie die Kontrolle über die generierte Datei durch den Designer. Schreiben Sie das Verhalten des Bildschirms in Window1.cs.

Ziehen Sie die Steuerelemente vom Toolbox auf das Fenster. Eine Beschriftung fragt nach dem Namen des Benutzers, ein Textfeld akzeptiert die Antwort und eine Schaltfläche führt die Begrüßung aus. Fügen Sie eine zweite Beschriftung für das Ergebnis hinzu. Jedes Steuerelement hat nun eine klare Rolle in der Interaktion.

Legen Sie Name und Text jedes Steuerelements im Eigenschaftenfenster fest. Name ist die von Ihrem Code verwendete Kennung; Text ist das, was der Benutzer sieht. Verwenden Sie txtName für die Eingabe, btnSayHello für die Schaltfläche und lblStatus für das Ergebnis. Die Überschriftenbezeichnung lautet lblTitle.

Doppelklicken Sie auf die Schaltfläche, um den Handler Click zu erstellen. Lesen Sie txtName.Text und kürzen Sie die Leerzeichen. Wenn das Ergebnis leer ist, setzen Sie lblStatus.Text auf eine Nachricht, die nach einem Namen fragt, und kehren Sie dann zurück. Andernfalls tragen Sie die Begrüßung in das Etikett ein. Die Validierung erfolgt vor der erfolgreichen Antwort.

Drücken Sie Start, um die Anwendung lokal auszuführen. Geben Sie beim Öffnen des Browsers einen Namen ein und klicken Sie auf „Sagen Sie Hallo“. Der Click-Handler wird ausgeführt und die Ergebnisbeschriftung zeigt die Begrüßung an. Sie haben einen visuell gestalteten Bildschirm mit C#-Code verbunden und die Antwort im Browser gesehen.

In dieser Lektion erstellen wir ein Wisej.NET-Dashboard im Visual Studio Designer. Wir werden seine Steuerelemente anordnen, ihnen aussagekräftige Namen geben und eine Schaltfläche mit einem Click-Handler verbinden. Sie sehen, welche Arbeit in das generierte Layout und welche in Ihren eigenen Code gehört.

Öffnen Sie DashboardWindow in der Entwurfsansicht. In diesem Fenster werden der Dienststatus, die Befehle und der Ereignisverlauf an einem Ort gesammelt, sodass Benutzer das Ergebnis jeder Aktion verstehen können, ohne den Bildschirm wechseln zu müssen.

Verwenden Sie den Designer, um Steuerelemente anzuordnen, Toolbox, um sie hinzuzufügen, und das Eigenschaftenfenster, um sie zu konfigurieren. Diese drei Oberflächen arbeiten zusammen: Wählen Sie ein Steuerelement auf der Leinwand aus, bevor Sie seine Eigenschaften ändern.

Fügen Sie eine Überschrift und eine separate Statusbeschriftung hinzu und platzieren Sie dann die drei Servicebeschriftungen in einem Bereich. Das Panel gruppiert verwandte Informationen, während der Gesamtstatus darüber leicht zu finden bleibt.

Fügen Sie die Schaltflächen „Start“, „Stopp“, „Zurücksetzen“ und „Aktualisieren“ hinzu, gefolgt von der Ereignisliste. Die Schaltflächen lösen Aktionen aus; Die Liste erklärt, was passiert ist. Wenn dieser Verlauf sichtbar bleibt, können wiederholte Aktionen leichter nachvollzogen werden.

Legen Sie Text für die Wörter fest, die der Benutzer sieht, und Name für die Kennung, die Ihr Code verwendet. Ein Name wie btnStart sollte den Zweck des Steuerelements identifizieren, damit sein Ereignishandler später leicht gefunden werden kann.

Doppelklicken Sie auf „Start“, um den Click-Handler zu erstellen. Aktualisieren Sie dort die Statusbezeichnungen und rufen Sie einen Helfer an, um das Ereignis anzuhängen. Durch die Wiederverwendung des Protokollierungshelfers bleibt der Ereignisverlauf über alle vier Befehle hinweg konsistent.

Schreibverhalten in der regulären C#-Datei des Fensters. Der Designer verwaltet seine eigene generierte Datei für die Steuerungserstellung und das Layout. Durch die Trennung dieser Verantwortlichkeiten wird verhindert, dass eine spätere Designänderung Ihre handgeschriebene Logik überschreibt.

Führen Sie das Projekt aus und warten Sie, bis der Browser geöffnet wird. Der von Ihnen entworfene Bildschirm ist jetzt die Benutzeroberfläche der laufenden Anwendung. Überprüfen Sie den Ausgangszustand, bevor Sie die Tasten testen.

Click Starten Sie und beobachten Sie, wie sich die drei Servicebezeichnungen in „Online“ ändern. Der Gesamtstatus lautet „Läuft“ und die Ereignisliste zeichnet die Aktion auf. Diese sichtbaren Änderungen sollten miteinander übereinstimmen.

Click Weiter stoppen. Jeder Dienst wird offline und ein neuer Eintrag zeichnet den Stopp auf. Durch Beibehalten des früheren Starteintrags kann der Benutzer die Abfolge der Aktionen und nicht nur den aktuellen Status sehen.

Click Zurücksetzen, um die Demonstration in den Ausgangszustand zurückzusetzen. Die vorherigen Protokolleinträge verschwinden und der Status wird in „Leer“ geändert. Zeichnen Sie den Reset selbst auf, damit der leere Verlauf eine verständliche Erklärung enthält.

Klicken Sie abschließend auf „Aktualisieren“, um den aktuellen Status erneut zu lesen und einen Protokolleintrag hinzuzufügen. Aktualisieren prüft den Status; es bedeutet nicht Starten oder Zurücksetzen. Eindeutige Befehle sollten eindeutige, verständliche Ergebnisse liefern.

Wir werden eine gemeinsame Shell für die Anwendung erstellen, sodass jede Seite dieselbe Navigation und dasselbe Layout verwendet. Die Kopfzeile, der Navigationsbereich, der Inhaltsbereich und die Statusleiste haben jeweils eine klare Rolle. Durch die Zentralisierung von Seitenänderungen können wir auch an einer Stelle die Berechtigungen des aktuellen Benutzers in der Navigation widerspiegeln.

Beobachten Sie, wie der äußere Rahmen an Ort und Stelle bleibt, während sich die zentrale Ansicht ändert. Diese gemeinsame Shell gibt jeder Funktion ein einheitliches Zuhause und vermeidet den Neuaufbau der Navigation auf jedem Bildschirm.

Ordnen Sie Kopfzeile, Navigation, Inhaltsbereich und Statusleiste als separate Bereiche an. Jeder hat eine andere Verantwortung: Orientierung, Auswahl einer Funktion, Erledigung der Arbeit und Berichterstattung über das Ergebnis.

Docken Sie die Kopfzeile oben, die Navigation links und die Statusleiste unten an. Lassen Sie den Inhalt den verbleibenden Raum ausfüllen, sodass bei der Größenänderung die Gesamtstruktur erhalten bleibt.

Leiten Sie jede Navigationstaste über NavigateTo weiter. Eine einzelne Methode kann dieselben Seitenwechselregeln konsistent anwenden; Separate Implementierungen in jeder Schaltfläche würden abweichen, wenn Funktionen hinzugefügt werden.

Folgen Sie NavigateTo durch den Seitenwechsel: Entfernen Sie den vorherigen Inhalt, laden Sie die ausgewählte Ansicht und aktualisieren Sie dann den Breadcrumb und den Status. Das Navigationsfeedback muss die tatsächlich angezeigte Ansicht beschreiben.

Die Einstellungen bleiben für den Support-Mitarbeiter sichtbar, in dieser Demonstration ist „Speichern“ jedoch deaktiviert. Dies veranschaulicht eine Berechtigung in der Schnittstelle; Die spätere Authentifizierungsarbeit muss auch die tatsächliche Autorisierung erzwingen.

Die Shell trennt jetzt die gemeinsame Navigation von wiederverwendbaren Feature-Ansichten. Wenn Sie eine Seite hinzufügen, verbinden Sie sie über dieselbe Navigationsmethode und prüfen Sie, ob der Standort und der Status klar bleiben.

Wir zeigen eine Liste der Tickets in einem DataGridView an und verknüpfen das ausgewählte Ticket mit den Detailkontrollen. Ein Dienst stellt die Daten bereit, während der Bildschirm die Auswahl und Anzeige koordiniert. Durch diese Trennung bleiben Datenbank- und Geschäftsentscheidungen von den Ereignishandlern der Benutzeroberfläche fern.

Erstellen Sie den Ticketeditor um ein gemeinsames Datenmodell herum, anstatt Werte zwischen unabhängigen Steuerelementen zu kopieren. Durch die Bindung wird der ausgewählte Datensatz mit dem Bildschirm verbunden, während der Dienst Ticketvorgänge abwickelt.

Platzieren Sie die Detailfelder auf der linken Seite und lassen Sie das Ticketraster die rechte Seite des geteilten Containers ausfüllen. Benutzer können einen Datensatz auswählen und seine Details überprüfen, ohne die Liste zu verlassen.

Ticket beschreibt die Felder in einem Datensatz. TicketService bietet Vorgänge wie Laden und Speichern. Der Bildschirm ruft diese Vorgänge auf, anstatt zum Ort zu werden, an dem Persistenzregeln implementiert werden.

Verbinden Sie die Liste und das Raster über einen BindingSource und binden Sie dann die Detailfelder an dieselbe Quelle. Durch die Freigabe des aktuellen Datensatzes bleiben Titel, Status, Priorität und Beschreibung an der Auswahl ausgerichtet.

Speichern Sie zuerst über TicketService und benachrichtigen Sie dann das Bindungssystem über ResetBindings. Das Aktualisieren der Anzeige erfolgt unabhängig vom Speichern der Daten: Ein aktualisiertes Raster allein beweist nicht, dass die Persistenz erfolgreich war.

Führen Sie den Editor aus und wählen Sie verschiedene Ticketzeilen aus. Beobachten Sie, wie die Detailfelder der Auswahl bis BindingSource folgen. Dies bestätigt, dass das Raster und der Editor denselben aktuellen Datensatz verwenden.

Ändern Sie den Status des ausgewählten Tickets und klicken Sie auf Ticket speichern. Folgen Sie dem Vorgang in den Dienst und zurück zum aktualisierten Raster. Die sichtbare Zeile sollte nun den von Ihnen gespeicherten Wert widerspiegeln.

Halten Sie die Verantwortlichkeiten für Modell, Service und Bildschirm getrennt. Wenn ein Wert falsch aussieht, erhalten Sie durch diese Trennung eine nützliche Frage: Ist der Datensatz falsch, ist das Speichern fehlgeschlagen oder ist die Anzeige veraltet?

Wir werden einen Dialog verwenden, um ein Ticket zu erstellen oder ein bestehendes zu bearbeiten. Das Dialogfeld überprüft erforderliche Felder und meldet den Erfolg erst, wenn der Vorgang erfolgreich war. Ticketvorgänge verbleiben in der Serviceebene, daher gelten für jeden Bildschirm, der den Dialog öffnet, dieselben Regeln.

Erstellen Sie einen fokussierten Dialog zum Eingeben eines Tickets und zum Bearbeiten eines vorhandenen Tickets. Geben Sie „Speichern“ und „Abbrechen“ unterschiedliche Ergebnisse an, sodass das Schließen des Dialogs nie stillschweigend bedeutet, dass Daten akzeptiert wurden.

Gruppieren Sie die Ticketfelder im Dialog und sorgen Sie dafür, dass Speichern und Abbrechen leicht zu finden sind. Der Dialog sollte eine zusammenhängende Änderung mit genügend Informationen erfassen, damit der Benutzer sie überprüfen kann, bevor er sie akzeptiert.

Initialisieren Sie denselben Dialog für jeden Workflow unterschiedlich. Neu beginnt mit leerer Eingabe; Bearbeiten lädt das ausgewählte Ticket. Durch die Wiederverwendung des Layouts bleiben die beiden Arbeitsabläufe konsistent, ohne dass ihre Ausgangszustände verwechselt werden.

Führen Sie ValidateForm aus, bevor Sie ein akzeptiertes Ergebnis zurückgeben. Wenn erforderliche Werte fehlen, lassen Sie den Dialog geöffnet. DialogResult.OK sollte eine gültige akzeptierte Eingabe kommunizieren und nicht nur, dass die Schaltfläche „Speichern“ gedrückt wurde.

Öffnen Sie „Neu“ und versuchen Sie, ohne Titel zu speichern. Die Meldung identifiziert die fehlenden Informationen und das Dialogfeld bleibt geöffnet, sodass der Benutzer die Möglichkeit hat, die Eingabe zu korrigieren, ohne den Vorgang neu starten zu müssen.

Füllen Sie die erforderlichen Felder aus und akzeptieren Sie den Dialog. Das übergeordnete Element ruft dann TicketService auf und aktualisiert das Raster. Befolgen Sie diese Reihenfolge, damit der Benutzer das Ergebnis der akzeptierten, gespeicherten Änderung sieht.

Wählen Sie ein vorhandenes Ticket aus und öffnen Sie Bearbeiten. Die aktuellen Werte sollten im selben Dialogfeld angezeigt werden. Ändern Sie ein Feld, speichern Sie es und überprüfen Sie, ob die entsprechende Zeile aktualisiert wird, anstatt ein weiteres Ticket zu erstellen.

Verwenden Sie für beide Arbeitsabläufe dieselbe Reihenfolge: Validieren, Akzeptieren, Speichern über den Dienst und Aktualisieren. Wenn diese Phasen explizit bleiben, können Abbruch- und Validierungsfehler einfacher und ohne versehentliche Schreibvorgänge behandelt werden.

Wir führen einen simulierten Export oder Import im Hintergrund durch und zeigen dessen Fortschritt an, ohne die Schnittstelle zu blockieren. Jeder verbundene Benutzer behält seinen eigenen Betriebsstatus. Außerdem behandeln wir Fehler mit einer nützlichen Meldung für den Benutzer, während interne Fehlerdetails nicht auf dem Bildschirm angezeigt werden.

Nutzen Sie die Export- und Importdemonstration, um einen Auftrag im Laufe der Zeit zu verfolgen. Ein reaktionsfähiger Bildschirm benötigt mehr als einen Fortschrittsbalken: Benutzer müssen verstehen, ob die Arbeit ausgeführt, abgeschlossen, abgebrochen oder fehlgeschlagen ist.

Halten Sie die Startbefehle, den Abbruch, den Fortschritt und das Protokoll gemeinsam sichtbar. Sie beantworten unterschiedliche Fragen: Was kann ich tun, wie weit ist die Arbeit fortgeschritten und was ist bereits passiert?

Warten Sie in RunJobAsync jeden Schritt ab und melden Sie seinen Fortschritt. Verwenden Sie den Fehlerhandler für Fehler und den finally-Block für die Bereinigung, damit die Schnittstelle ihren ausgelasteten Zustand auch dann verlassen kann, wenn die Arbeit fehlschlägt.

Starten Sie den Import und beobachten Sie, wie sich die Steuerelemente ändern, während der Job ausgeführt wird. Deaktivieren Sie Befehle, die mit dem aktiven Vorgang in Konflikt geraten würden, aber halten Sie Fortschritt und Feedback verfügbar, damit der Benutzer die Arbeit verfolgen kann.

Behalten Sie den Fortschritt und andere benutzerspezifische Werte in der aktuellen Sitzung bei. Ein statisches Feld wird von allen Benutzern gemeinsam genutzt, sodass das Speichern des Jobstatus einer Person dort dazu führen kann, dass eine andere Person ihn sieht oder ändert.

Aktivieren Sie „Fehler simulieren“ und führen Sie den Job erneut aus. Behalten Sie Diagnosedetails zur Untersuchung im Protokoll, während der Benutzer eine kurze Sicherheitsnachricht erhält. Technische Ausnahmedetails sollten nicht öffentlicher Fehlertext werden.

Die Schaltfläche leitet den Vorgang ein, der Job führt die Arbeit aus und der Bildschirm meldet seinen Status. Halten Sie diese Rollen getrennt, damit Erfolg, Abbruch und Misserfolg die Schnittstelle wieder in einen nutzbaren Zustand versetzen können.

Wir werden das Erscheinungsbild des Dashboards mithilfe eines integrierten Designs, von Karten und einer einheitlichen Navigation aktualisieren. Die vorhandenen Dienste, die Validierung und die Datenbindung werden weiterhin ihre Aufgaben erfüllen. Dadurch können wir die Art und Weise verbessern, wie Benutzer den Bildschirm lesen und navigieren, ohne das Geschäftsverhalten der Anwendung neu zu schreiben.

Modernisieren Sie den vorhandenen Bildschirm, ohne sein Verhalten neu zu gestalten. Ein Wisej.NET-Theme bietet konsistente visuelle Optionen; Verbesserungen im Layout und in der Navigation machen die Anwendung dann leichter verständlich.

Machen Sie den Seitentitel leicht erkennbar, gruppieren Sie verwandte Messwerte und platzieren Sie Befehle neben dem Inhalt, auf den sie sich auswirken. Die visuelle Hierarchie soll Benutzern bei der Entscheidung helfen, wo sie suchen und was als nächstes zu tun ist.

Die Themenauswahl ändert Application.Theme.Name, während SetActiveButton das ausgewählte Navigationselement markiert. Behandeln Sie Aussehen und Standort als separate Aspekte, damit Benutzer nach dem Wechsel des Themas immer noch wissen, wo sie sich befinden.

Wechseln Sie zwischen den integrierten Designs und vergleichen Sie dieselben Steuerelemente. Ihr Aussehen ändert sich, während der Arbeitsablauf gleich bleibt. Überprüfen Sie die Lesbarkeit und den aktiven Status, anstatt das Thema nur anhand seiner Farben zu beurteilen.

Überprüfen Sie das fertige Dashboard als Ganzes. Konsistente Abstände, Karten und Navigation sollten die bestehende Datenbindung und -validierung unterstützen. Eine visuelle Auffrischung gelingt, wenn der gewohnte Arbeitsablauf klarer wird.

Wir werden eine kleine JavaScript-Statusvisualisierung zu einem Wisej.NET-Bildschirm hinzufügen. Native Steuerelemente übernehmen weiterhin die normale Interaktion und C# ist Eigentümer der Daten, Entscheidungen und Protokollierung. Das Widget zeigt die empfangenen Werte an und bietet uns so eine spezielle visuelle Darstellung, ohne eine zweite Quelle für den Anwendungsstatus zu erstellen.

Fügen Sie der vorhandenen Wisej.NET-Anwendung eine kleine JavaScript-Visualisierung hinzu. Behalten Sie die Hauptlogik in C# bei, damit die zusätzliche Visualisierung nicht zum zweiten Eigentümer der Anwendungsentscheidungen wird.

Verwenden Sie native Wisej.NET-Beschriftungen, Schaltflächen und Protokollierung für die normale Interaktion. Führen Sie einen Widget nur für das spezialisierte Visual ein. Dadurch bleibt die Integration fokussiert, anstatt Steuerelemente zu ersetzen, die das Problem bereits lösen.

Senden Sie dem Widget nur die Anzeigewerte, die es benötigt: Status, Ticketanzahl und Systemlast. C# bleibt für diese Werte verantwortlich; Die Browservisualisierung stellt sie dar, ohne unabhängige Serverdaten zu empfangen.

Der Schaltflächenhandler aktualisiert die nativen Beschriftungen und sendet dieselben Daten über UpdateWidget. Die Verwendung eines Ergebnisses für beide Präsentationen verhindert, dass Text und Visualisierung unterschiedliche Zustände beschreiben.

Click Aktualisieren Sie die Serverdaten und vergleichen Sie die Beschriftungen mit dem Widget. Sie sollten sich im selben Serverbetrieb gemeinsam ändern. Wenn sie nicht einverstanden sind, überprüfen Sie die über die Integrationsgrenze weitergeleiteten Daten.

Versuchen Sie es nacheinander mit „Gesund“, „Warnend“ und „Kritisch“. Die C#-Ereignisse aktualisieren den visuellen Zustand und zeichnen die Änderung auf. Der Ereignisverlauf hilft zu erklären, warum das Widget sein aktuelles Aussehen hat.

Wir prüfen den Antrag, bevor wir ihn zur Veröffentlichung verpacken. Konfiguration, Geheimnisse, Protokollierung und Berechtigungen erfordern jeweils eine explizite Prüfung. Der Release-Workflow nutzt diese Prüfungen, um zu entscheiden, ob das Paket bereit ist, und hält gleichzeitig vertrauliche Details aus Nachrichten, die an den Benutzer gerichtet sind, fern.

Nutzen Sie den Überprüfungsbildschirm, um Beweise vor der Veröffentlichung zu sammeln. Konfigurations-, Sicherheits- und Bereitstellungsprüfungen gehören zu einem wiederholbaren Prozess, sodass die Bereitschaft eher von abgeschlossenen Prüfungen als von einem beruhigenden Eindruck abhängt.

Notieren Sie zunächst die Umgebung, das Hosting-Ziel, die Version und den Prüfer. Diese Details geben genau an, was überprüft wird. Eine ausgefüllte Checkliste für eine Umgebung deckt nicht automatisch ein anderes Release-Ziel ab.

Arbeiten Sie die erforderlichen Konfigurationsprüfungen getrennt von optionalen Notizen durch. Ein Hinweis kann eine Ausnahme erklären, sollte aber nicht dazu führen, dass eine fehlende erforderliche Prüfung aus der Bereitschaftsentscheidung verschwindet.

Halten Sie Geheimnisse und detaillierte Ausnahmen aus der Bewertungsanzeige fern. Zeigen Sie eine sichere Zusammenfassung an und hinterlassen Sie Diagnosedetails in Serverprotokollen, damit das Überprüfungspaket ohne Offenlegung von Anmeldeinformationen geteilt werden kann.

Trennen Sie Bereitschaft von Erlaubnis. Durch erforderliche Prüfungen wird festgestellt, ob die Überprüfung abgeschlossen ist, während eine Rollenprüfung bestimmt, wer das Paket erstellen darf. Durch das Bestehen der Checkliste erhält der Benutzer keine zusätzliche Berechtigung.

Vervollständigen Sie die verbleibenden erforderlichen Aufgaben und beobachten Sie, wie die Zahl neun von neun erreicht. Der Status ändert sich in „Bereit zur Überprüfung“. Das bedeutet, dass die Checkliste vollständig ist und nicht, dass die Bereitstellung bereits stattgefunden hat.

Erstellen Sie das Überprüfungspaket und prüfen Sie dessen Zusammenfassung, einschließlich bekannter Probleme und Rollback-Informationen. Eine nützliche Übergabe teilt dem Prüfer mit, was fertig ist, was noch ungewiss ist und wie er sich wiederherstellen kann, wenn die Veröffentlichung fehlschlägt.

Modul zehn. Erstellen Sie den Mini-Helpdesk Wisej.NET. Dieses Abschlussprojekt vereint den Kurs in einer Anwendung. Wir folgen der Navigation, dem Ticket-Workflow und den unterstützenden Bildschirmen und schauen uns dann an, was das Projekt für die Überprüfung und Bereitstellung bereit macht.

Beginnen Sie mit der fertigen Anwendung und folgen Sie der Navigationsshell. Die separaten Kursbeispiele haben jetzt ein gemeinsames Layout, sodass Benutzer zwischen den Funktionen wechseln können, ohne jedes Mal ein neues Navigationsmuster erlernen zu müssen.

Verfolgen Sie Tickets, Kunden und Jobs während ihrer Hauptinteraktionen. Raster stellen Datensätze dar, Dialoge sammeln Änderungen und Hintergrundjobs melden den Fortschritt. Überprüfen Sie nach jeder Aktion, ob das sichtbare Ergebnis erklärt, was tatsächlich passiert ist.

Verfolgen Sie eine Ticketänderung über alle Verantwortlichkeiten hinweg. Der Dialog validiert die Eingabe, TicketService übernimmt den Vorgang und das Raster präsentiert das Ergebnis. Konsistente Beschriftungen und Statusmeldungen verbinden diese Phasen für den Benutzer.

Verwenden Sie „Bereitstellung und Architektur“, um die Anwendung über die Bildschirme hinaus zu erläutern. Überprüfen Sie Konfiguration, Sicherheit und Protokollierung und verfolgen Sie dann die Daten über die Serviceschicht. Eine Arbeitsdemonstration soll auch deren Organisation verständlich machen.

Schließen Sie mit der Codeüberprüfung und den nächsten Schritten ab. Überprüfen Sie sinnvolle Namen und klare Verantwortlichkeiten und erfassen Sie dann die verbleibende Arbeit bis zum Produktivbetrieb. Das Abschlussprojekt demonstriert eine funktionierende Anwendung und macht gleichzeitig unvollendete Arbeiten und Designentscheidungen deutlich.