Kurs Anwendungsintegration

Folgen Sie einer Integration über den Server und den Browser. Wisej.NET besitzt den Komponentenstatus, während ein Browser-Widget ihn anzeigt. Durch die explizite Beibehaltung dieser Grenze wird verhindert, dass die Anbieterbibliothek zur Geschäftsschicht der Anwendung wird.

Unterscheiden Sie die Komponente von ihrem Widget. Die Komponente besitzt den Anwendungsstatus; Das Widget verwaltet das Browserverhalten. Ereignisse verbinden sie, indem sie sinnvolle Änderungen melden, anstatt jede Browser-Interaktion zurück auf den Server zu kopieren.

Verfolgen Sie die Daten nach außen als kompaktes JSON und dann in die Optionen des Anbieters. Verfolgen Sie wichtige Ereignisse bis zum Server zurück. Diese Adaptergrenze ermöglicht es dem Servercode, mit einem stabilen Vertrag statt mit herstellerspezifischen Details zu arbeiten.

Überprüfen Sie TemperatureGauge im Designer. Value ist die Eigenschaft, die die Anwendung ändert; ThresholdExceeded ist das Ereignis, das es behandelt. Das Messgerät des Herstellers bleibt in dieser bekannten Wisej.NET-Komponentenschnittstelle.

Beobachten Sie, wie der Server Value ändert und wie die Anzeige ihn rendert. Beim angezeigten Schwellenwert kehrt ein Ereignis mit nützlichen Informationen zurück. Die Anwendung reagiert auf das Überschreiten des Schwellenwerts, nicht auf jeden visuellen Animationsrahmen.

Klassifizieren Sie Messgerät, Editor und Raster, bevor Sie Integrationscode schreiben. Ihre Ressourcen-, Daten- und Ereignisanforderungen sind unterschiedlich. Ein erster Vergleich dieser Anforderungen hilft bei der Auswahl einer ausreichenden Integrationsoberfläche ohne unnötige Komplexität.

Schreiben Sie einen Architekturentscheidungsbericht, in dem Sie Ihre Wahl erläutern. Berücksichtigen Sie Wiederverwendungs-, Design-, Sicherheits- und Wartungsbeschränkungen. Es geht darum, die Begründung zu bewahren, damit ein anderer Entwickler später beurteilen kann, ob die Wahl noch passt.

Senden Sie das Diagramm, die Vergleichstabelle und den Entscheidungsdatensatz zusammen. Sie sollten eine konsistente Geschichte erzählen: wo der Zustand gespeichert wird, wie das Widget kommuniziert und warum der gewählte Integrationsansatz seinen Anforderungen entspricht.

Sie haben jetzt ein Integrationsdesign, das jemand anderes überprüfen kann. Nutzen Sie dieses gemeinsame Verständnis als Ausgangspunkt für Implementierung und Tests, anstatt ein funktionierendes Visual als die gesamte Integration zu betrachten.

Beweisen Sie das Verhalten von JavaScript, bevor Sie es in Wisej.NET einschließen. Ein kleines isoliertes Beispiel hilft dabei, einen Bibliotheks- oder Sprachfehler von einem durch die Integration selbst verursachten Problem zu unterscheiden.

Überprüfen Sie im Rückruf des Anbieters, worauf sich this bezieht. Möglicherweise handelt es sich um das Vendor-Objekt, das über keine fireWidgetEvent-Methode verfügt. Die Methode fehlt, weil der Empfänger falsch ist, nicht weil Wisej.NET das Ereignis verloren hat.

Behalten Sie einen expliziten Verweis auf das Widget in einem Abschluss bei, binden Sie den Rückruf oder rufen Sie eine Widget-Methode auf. Jede Lösung gibt dem Rückruf eine zuverlässige Route zur richtigen Instanz, wenn der Anbieter ihn aufruft.

Deklarieren Sie Abhängigkeiten in der erforderlichen Reihenfolge: unterstützende Bibliothek, Stile, Herstellerskript, dann Initialisierung. Packages macht diese Reihenfolge explizit und verhindert so, dass die Initialisierung ausgeführt wird, bevor die erforderlichen Ressourcen vorhanden sind.

Verschieben Sie die bewährte Initialisierung in den InitScript von Widget und deklarieren Sie seine Ressourcen in Packages. Behalten Sie die gleichen Abhängigkeitsannahmen wie im isolierten Beispiel bei, damit sich durch die Integration nicht unbemerkt die Art und Weise ändert, wie die Bibliothek startet.

Verwenden Sie die Browser-Entwicklertools, um die gespeicherte Anbieterinstanz zu überprüfen und valueChanged zu befolgen. Ein sourceURL gibt dem eingefügten Code einen erkennbaren Namen; Eine Debugger-Anweisung hilft dabei, dort anzuhalten, wo der Rückruf tatsächlich ausgeführt wird.

Behalten Sie das isolierte Beispiel, die Arbeitsausführung InitScript und die Debugging-Notizen bei. Ein zukünftiger Fehler kann dann außerhalb der Integration reproduziert und mit dem tatsächlichen Widget-Setup verglichen werden.

Die Integration verfügt nun über einen getesteten Ausgangspunkt, explizite Abhängigkeiten und einen zuverlässigen Rückrufkontext. Diese Grundlagen erleichtern das Debuggen von späterem Wrapper-Code, da das grundlegende Verhalten von JavaScript bereits verstanden wird.

Beginnen Sie mit einem Widget, um die Integration schnell nachzuweisen. Dadurch erhält die Anbieterbibliothek einen Platz innerhalb von Wisej.NET, bevor Sie in ein wiederverwendbares Steuerelement mit einer größeren öffentlichen Schnittstelle investieren.

Platzieren Sie den Widget auf dem Armaturenbrett und halten Sie das erste Exemplar klein. Die unmittelbare Frage ist, ob die Ressourcen geladen werden und das Anbieterobjekt in seinem Container ausgeführt werden kann, und nicht, ob die Abstraktion abgeschlossen ist.

Geben Sie Packages, Options und InitScript separate Jobs an. Packages lädt Abhängigkeiten, Options trägt die aktuellen Daten und InitScript erstellt das Visual. Wenn diese Rollen klar bleiben, lässt sich eine fehlgeschlagene Integration leichter diagnostizieren.

Erstellen Sie die Anbieterinstanz während der Initialisierung und aktualisieren Sie dann die vorhandene Instanz, wenn sich die Optionen ändern. Wenn Sie es bei jedem Update neu erstellen, können Handler dupliziert werden oder der Status des aktuellen Widgets verloren gehen.

Verwenden Sie die Serverschaltfläche, um Options zu ändern und beobachten Sie, wie das Update das Bild aktualisiert. Ein Anruf in der Warteschlange verarbeitet einen zwingenden Befehl. Unterscheiden Sie zwischen der Änderung des dauerhaften Widget-Status und der Anforderung einer einmaligen Client-Aktion.

Senden Sie die Ressourcendeklarationen, die Initialisierung, die Aktualisierungslogik und die Serverinteraktion zusammen. Sie sollten sowohl die erste Erstellung als auch spätere Änderungen demonstrieren. Die Wiederverwendung über mehrere Bildschirme hinweg ist der nächste Grund für die Einführung eines Wrappers.

Der Prototyp hat nun gezeigt, dass die Bibliothek innerhalb von Wisej.NET laden, rendern und reagieren kann. Übertragen Sie diese bewährten Verhaltensweisen in eine wiederverwendbare Hülle, anstatt den Prototyp auf jede Seite zu kopieren.

Verschieben Sie wiederholte Widget-Einrichtungen in eine wiederverwendbare Klasse. Wenn sich Ressourcenpfade oder Initialisierungen ändern, sollte eine verwaltete Implementierung jeden Bildschirm bedienen, anstatt Änderungen an mehreren kopierten Skripten zu erfordern.

Lassen Sie SimpleGauge das Verhalten von Wisej.NET Widget erben und dessen Packages, Options und InitScript besitzen. Die Seite sollte nach dem Messgerätverhalten in der Klasse fragen, ohne zu wissen, wie die Anbieterbibliothek zusammengestellt ist.

Machen Sie Value, Minimum, Maximum und Caption als typisierte Eigenschaften verfügbar. Beschreibungen und Kategorien helfen dem Designer-Benutzer bei der Auswahl gültiger Einstellungen, während der Wrapper diese Einstellungen intern in die Optionen des Anbieters übersetzt.

Halten Sie die unterstützten Eigenschaften öffentlich und blenden Sie gegebenenfalls Implementierungsdetails aus. Wenn Aufrufer Initialisierungs- oder Rohoptionen frei ersetzen können, können sie die Garantien umgehen, die den Wrapper zuverlässig machen.

Platzieren Sie die Klasse auf einer Demonstrationsseite und ändern Sie sie über normale Eigenschaften. Das Fehlen von seitenspezifischem InitScript ist ein nützlicher Beweis: Das Integrationswissen steckt tatsächlich in der wiederverwendbaren Klasse.

Stellen Sie die Klasse mit dokumentierten Eigenschaften, Standardwerten und einer sauberen Beispielseite bereit. Ein Prüfer sollte in der Lage sein, es zu instanziieren und die unterstützten Einstellungen zu verstehen, ohne das Initialisierungsskript des Anbieters öffnen zu müssen.

Eine gute Verpackung macht den normalen Betrieb unkompliziert und verhindert einen versehentlichen Missbrauch. Bewerten Sie die öffentliche Schnittstelle aus der Sicht des Seitenautors, nicht nur aus der Sicht der Person, die die Integration erstellt hat.

Erstellen Sie ein benutzerdefiniertes Steuerelement, wenn sich die Integration wie ein Teil von Wisej.NET selbst verhalten muss. Das Ziel ist eine wiederverwendbare Komponente, die am Entwurfszeitverhalten und der Themengestaltung beteiligt ist, und nicht nur ein gehostetes visuelles Element.

Vergleichen Sie einen Widget-Wrapper mit einem Control auf Plattformebene. Wählen Sie die stärkere Integration, wenn natives Verhalten und Themenbeteiligung dies rechtfertigen; Zusätzliche Implementierungsarbeit sollte eine echte Wiederverwendungsanforderung erfüllen.

Koppeln Sie den Server SimpleGaugeControl mit seiner Client-Klasse unter Platform. Die beiden Klassen haben unterschiedliche Verantwortlichkeiten: Der Server stellt den Anwendungsstatus bereit, während der Client implementiert, wie dieser Status im Browser angezeigt wird und sich verhält.

Verwenden Sie OnWebRender, um eine bewusste Client-Konfiguration zu erstellen. Schließen Sie die zum Rendern des Messgeräts erforderlichen Eigenschaften ein, anstatt nicht verwandte Serverobjekte zu serialisieren. Eine kleine explizite Grenze ist einfacher zu begründen und aufrechtzuerhalten.

Verbinden Sie den Darstellungsschlüssel mit der Designdefinition. Dadurch kann das Design die visuellen Entscheidungen steuern, anstatt für jeden Bildschirm, der das Steuerelement verwendet, ein separates Erscheinungsbild fest zu programmieren.

Überprüfen Sie das Steuerelement im Designer und probieren Sie seine Größen- und Designeinstellungen aus. Das Design-Time-Rendering ist Teil der Integration: Andere Entwickler müssen die Steuerung anordnen, ohne zuerst die gesamte Anwendung auszuführen.

Reichen Sie beide Klassen, den Auftrittseintrag und den Entwurfszeitnachweis ein. Zusammen demonstrieren sie den vollständigen Pfad von der Servereigenschaft zu einem thematischen Steuerelement, das ein anderer Entwickler visuell platzieren kann.

Beobachten Sie auf dem Dashboard, wie mehrere Instanzen dieselbe Steuerungsimplementierung nutzen. Ihre Werte variieren, aber ihr Verhalten und ihre Themenintegration bleiben konsistent. Diese Konsistenz ist der Vorteil der einmaligen Kapselung der Integration.

Entscheiden Sie, ob jede Interaktion einen Befehl sendet oder ein Ergebnis benötigt. Diese Unterscheidung bestimmt, wie der Servercode weiterläuft, welche Daten die Grenze überschreiten und ob er auf eine Browserantwort warten muss.

Verwenden Sie Call, wenn der Browser eine Aktion ausführen soll und kein Rückgabewert erforderlich ist. Der Befehl befindet sich in der Warteschlange, sodass nachfolgender Servercode nicht davon ausgehen darf, dass der Browser die Ausführung bereits abgeschlossen hat.

Verwenden Sie CallAsync oder EvalAsync, wenn der nächste Schritt von einem Browserergebnis abhängt. Warten Sie den Vorgang ab, bevor Sie dieses Ergebnis verwenden, damit der Workflow der Antwort folgt und nicht mit fehlenden Daten fortfährt.

Definieren Sie ein kleines Datenübertragungsobjekt und überprüfen Sie seine serialisierten Eigenschaftsnamen. Der Browser erhält den serialisierten Vertrag, nicht das ursprüngliche C#-Objekt. Explizite Felder vermeiden die Offenlegung unabhängiger Zustände und reduzieren Namenskonflikte.

Vergleichen Sie die Live-Operationen: Ein Befehl ändert die Anzeige, ein erwarteter Aufruf liest seine gerenderte Größe und ein kompaktes Objekt gibt den Auswahlstatus zurück. Jeder Austausch überträgt nur das, was diese bestimmte Interaktion erfordert.

Geben Sie Beispiele für unidirektionale Befehle und erwartete Ergebnisse sowie den Rückgabedatenvertrag an. Ein Prüfer sollte erkennen können, wo die Ausführung wartet und welche Felder der Browser zurückgeben darf.

Halten Sie die Grenze rund um Befehle, Ergebnisse und explizite Datenverträge organisiert. Dadurch werden Timing und Verantwortung sichtbar, was zuverlässiger ist, als Browsercode als synchrone Erweiterung des Servers zu behandeln.

Behandeln Sie Rückrufe von Anbietern als Roheingaben für die Integration. Die Anwendung benötigt einen stabilen Satz aussagekräftiger Ereignisse, daher muss der Adapter entscheiden, was weitergeleitet werden soll, anstatt jede Anbieterbenachrichtigung direkt offenzulegen.

Trennen Sie visuelle Aktivitäten von Anwendungsentscheidungen. Zeigerbewegungen oder Animationen können lokal bleiben, während eine sinnvolle Auswahl oder Statusänderung möglicherweise den Server erfordert. Das Filtern an dieser Grenze vermeidet unnötigen Datenverkehr und Handlerarbeit.

Registrieren Sie den Anbieterrückruf einmal während der Initialisierung und leiten Sie ein kompaktes benanntes Ereignis weiter. Eine erneute Registrierung bei jedem Update kann dazu führen, dass eine Benutzeraktion unerwartet mehrere Server-Handler auslöst.

Verwenden Sie die Ereignisroute, die der Integrationsoberfläche entspricht. Widgets weiterleiten über fireWidgetEvent und WidgetEvent; Benutzerdefinierte Steuerelemente verwenden ihre Clientereignisse und OnWebEvent. Durch das Mischen der Routen werden Daten an den falschen Verarbeitungsmechanismus gesendet.

Definieren Sie jeden Ereignisnamen und jede Nutzlast, bevor Sie die Handler verbinden. Schwellenwertüberschreitungen, Wertänderungen und Punktauswahlen erfordern unterschiedliche Informationen. Kleine explizite Verträge machen deutlich, worauf sich ein Server-Handler verlassen kann.

Interagieren Sie mit der Anzeige, dem Knopf und dem Diagramm und verfolgen Sie die Ereignisse, die den Server erreichen. Stellen Sie sicher, dass jede Nutzlast die relevanten Werte enthält und dass die lokale visuelle Aktivität nicht zu einem Strom unnötiger Servernachrichten geworden ist.

Senden Sie gepaarte Client- und Server-Handler mit der Vertragstabelle. Ein Prüfer sollte in der Lage sein, jedes Ereignis von seinem Browser-Auslöser bis zur Serverentscheidung zu verfolgen, einschließlich der genauen Angabe, welche Daten die Grenze überschreiten.

Einige Anbieter-Widgets rufen ihre eigenen Daten ab, anstatt alles über Options zu empfangen. Geben Sie diesen Anfragen einen expliziten Endpunkt und behalten Sie den richtigen Komponentenkontext bei, sodass die Antwort dem vorgesehenen Benutzer und Widget gehört.

Verwenden Sie getPostbackUrl, wenn ein Widget eine Datenadresse erwartet. Es leitet die Anfrage an die entsprechende Sitzung und Komponenteninstanz weiter. Die Adresse liefert Kontext, aber der Handler muss den angeforderten Vorgang noch validieren.

Überprüfen Sie in WebRequest die angeforderte Aktion, bevor Sie Daten erstellen. Legen Sie den Inhaltstyp JSON fest und schreiben Sie die erwartete Antwortform. Eine gültige Transportantwort reicht nicht aus, wenn das Widget seinen Inhalt nicht interpretieren kann.

Verwenden Sie einen WebMethod für einen typisierten Vorgang, den Ihr Clientcode direkt aufruft. Argumente und der zurückgegebene Wert bilden den Vertrag, sodass der Aufrufer auf ein Ergebnis warten kann, anstatt eine Datenanforderung im Besitz des Widgets zu verwalten.

Wählen Sie den Endpunktstil danach aus, wer die Anfrage initiiert und steuert. Eine Anbieterdatenquelle verwendet natürlich ihre Adresse; Anwendungscode, der eine benannte Operation aufruft, profitiert von einer typisierten Methode und einem expliziten Ergebnis.

Folgen Sie der Anforderung des Rasters an den Postback-Handler und zurück zu den gerenderten Zeilen. Überprüfen Sie die Antwortstruktur an dieser Grenze. Ein leeres Raster kann auf eine Vertragsinkongruenz hinweisen, auch wenn die Anfrage selbst erfolgreich war.

Stellen Sie beide Endpunktbeispiele bereit und erläutern Sie die beabsichtigten Aufrufer. Überprüfen Sie die Autorisierung und Eingabevalidierung für jeden Pfad. Die Wahl eines geeigneten Endpunktmechanismus entbindet niemals die Verantwortung des Servers, den Betrieb zu schützen.

Verwenden Sie die Raster- und Pivot-Beispiele, um das Integrationsmuster unter der herstellerspezifischen Syntax zu identifizieren. Unabhängig von der gewählten Bibliothek benötigt die Anwendung weiterhin das Laden von Ressourcen, Datenoperationen, Ereignisse und eine stabile Wisej.NET-Schnittstelle.

Geben Sie dem Adapter das Eigentum an Erstellung, Optionen, Ereignissen und Datenzugriff. Durch die Zusammenhaltung dieser anbieterbezogenen Details wird verhindert, dass einzelne Seiten ihre eigenen inkompatiblen Versionen derselben Integration entwickeln.

Vergleichen Sie DataSource und CustomStore anhand der von ihnen angeforderten Operationen, nicht nur anhand ihrer Syntax. Beide benötigen einen Pfad zum Laden und Ändern von Daten. Der Adapter übersetzt seine Argumente in den Vertrag Ihres Servers.

Definieren Sie Paging, Sortierung und Filterung in GridOperationRequest, bevor Sie Handler implementieren. Validieren Sie diese Eingaben auf dem Server und ordnen Sie sie dann dem unterstützten Vorgang zu. Vom Browser bereitgestellte Abfrageanweisungen sind immer noch nicht vertrauenswürdige Eingaben.

Geben Sie separate Nutzlasten für Zeilenänderungen, Einfügungen, Löschungen und Auswahlereignisse an. Jeder sollte den beabsichtigten Vorgang und die erforderlichen Werte identifizieren, ohne eine ganze Komponente zu senden oder einen nicht zugehörigen Serverstatus offenzulegen.

Verfolgen Sie das Paginieren, Sortieren und Bearbeiten über denselben Serververtrag, während der Pivot seine Daten lädt. Die gemeinsame Grenze sorgt dafür, dass Anwendungsvorgänge auch dann verständlich bleiben, wenn die Browser-Widgets Schnittstellen unterschiedlicher Anbieter verwenden.

Übermitteln Sie den Betriebsvertrag, die Handler, die Event-Nutzlasten und den Pivot-Plan als einen zusammenhängenden Entwurf. Ein Prüfer sollte in der Lage sein, jede sichtbare Datenaktion mit einem expliziten, validierten Servervorgang zu verknüpfen.

Betrachten Sie die Integration als etwas, das wiederholter Nutzung und Bereitstellung standhalten muss. Ein erfolgreiches erstes Rendering beweist nur einen Weg; Die Produktivreife hängt auch von der Fehlerbehandlung, Updates, Bereinigung und wartbaren Verträgen ab.

Überprüfen Sie Ressourcenpfade, Ereignisvolumen, Lebenszyklusbereinigung, Timing und realistische Datengrößen. Diese Bedenken können bei einer kleinen Demonstration verborgen bleiben und dann zu Fehlern werden, wenn dasselbe Widget wiederverwendet oder an anderer Stelle bereitgestellt wird.

Name injiziert Skripte mit sourceURL und schlägt eindeutig fehl, wenn Voraussetzungen fehlen. Vergleichen Sie das Beispiel des isolierten Anbieters mit der integrierten Version. Das gibt Ihnen Hinweise darauf, wo der Fehler beginnt, anstatt sich auf Vermutungen zu verlassen.

Aktualisieren Sie die vorhandene Anbieterinstanz und zerstören Sie sie, wenn die Kontrolle verworfen wird. Wiederholte Erstellungs- und Schließzyklen sollten Handler oder Objekte nicht am Leben lassen, nachdem ihr Bildschirm verschwunden ist.

Starten Sie die Hintergrundverarbeitung über Application.StartTask. Wenn das Ergebnis vorliegt, aktualisieren Sie den Client und rufen Sie Application.Update auf. Erst wenn der Browser den neuen Status des Servers tatsächlich anzeigen kann, ist der Workflow abgeschlossen.

Integrieren Sie ein unbekanntes Widget mit denselben Grenzen: einen wiederverwendbaren Wrapper, Serverbefehle, ein bedeutungsvolles Ereignis und einen geschützten Datenendpunkt. Die Übung testet, ob Sie das Muster über die Beispiele des Kurses hinaus übertragen können.

Überprüfen Sie das Dashboard als mehrere Integrationen, die zusammenarbeiten. Verfolgen Sie Ereignisse, Aufrufe, Laden und Löschen für jedes Widget. Der gemeinsam genutzte visuelle Raum sollte nicht verwischen, welcher Wrapper die jeweilige Ressource und Interaktion besitzt.

Schließen Sie mit einem Wrapper ab, den ein anderer Entwickler verstehen, testen und wiederverwenden kann. Erläutern Sie den öffentlichen Auftrag und den Lebenszyklus, einschließlich des Fehlerverhaltens. Das dauerhafte Ergebnis ist eine wartbare Integration und nicht nur eine beeindruckende Demonstration.