Implementierungshandbuch › Beispiele für Fallstudien › Beispiele für das Schreiben einer effektiven Business-Logik

Beispiele für das Schreiben einer effektiven Business-Logik

Die "Best Practice"-Empfehlungen zur Art und Weise, wie eine effektive Business-Logik geschrieben wird, werden anhand der folgenden Themen aufgezeigt:

• Geclusterte Metriken
  • Wenn Sie die Größe des Systems beurteilen, zählen Sie eine geclusterte Metrik als Anzahl der Objekte in der Metrik. Denken Sie daran, dass alles multipliziert wird.
  • Eine Neuberechnung eines Cluster-Objekts bedeutet, die Neuberechnung des ganzen Clusters. Beachten Sie dies also, wenn Sie das Clustering und die Art und Weise, wie Adapter konfiguriert werden, planen und die Ressourcenstruktur ändern.
  • Dieselben Rohdaten-Events, die an viele Cluster-Objekten übermittelt werden, haben hohe Leistungskosten (Kontextschaltung)
• Globale Variablen
  • Fügen Sie Parameter und Attributwerte an jede Stelle im Code ein, wo sie erforderlich sind. Vermeiden Sie, sie als globale Variable einzufügen, besonders in geclusterten Metriken (dies würde die Größe des "Status" erhöhen)
  • Vermeiden Sie eine Logik, die große Zuordnungsgrafiken verarbeitet. Verarbeiten Sie stattdessen jedes Event in der OnXXEvent-Methode
  • Entfernen Sie so früh wie möglich Objekte aus den Zuordnungsgrafiken. Zum Beispiel, wenn ein Ticket geschlossen wird und nicht erst am Ende des Zeitraums
• Designmuster

  Das vordefinierte Inhaltspaket enthält mehrere Designmuster für übliche Szenarien. Die Verwendung dieser Designmuster kann die Leistung verbessern

• Integrierte Funktionalität

  ACE verfügt über ein integrierte Funktionalität und Tools für verschiedene Zwecke, wie z. B.:

  • Zeitfenster-Funktionalität
    • NetTime
    • IsWithinTimeslot
  • Zeit der Events
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Kontextobjekt
    • Enthält viele umgebungssensitive Methoden
    • Verwenden Sie diese Methoden und vermeiden Sie "Sichere ODBC"
• Ausgaben der Business-Logik

  Behalten Sie die Struktur in "T_SLALOM_OUTPUTS" bei. Dies bedeutet, dass es hilfreich ist, ähnliche logische Felder im selben physikalischen Feld zu platzieren, wenn Sie mehrere logische Tabellen mit einer ähnlichen Struktur in "T_SLALOM_OUTPUTS" haben. Dies ermöglicht eine einfache Indexierung zur Verbesserung der Berichtsleistung

• Event-Wiederverwendbarkeit

  Tun Sie dies, wenn Folgendes vorliegt:

  • Wenn mehrere Metriken die erste Phasenberechnung durchführen, die selbst für den Vertrag benötigt wird, und Events für eine Übersichtsmetrik senden, die das Ergebnis berechnet (z. B. Finanzkalkulation, KPI mit hohem Level)
  • Wenn eine einzelne Metrik eine vorläufige Aggregation von Rohdaten ausführt und Events an mehrere verschiedene Metriken sendet. Sinnvoll, wenn die Metrik erheblich weniger Events sendet, als sie empfängt, oder bedeutende Berechnungen ausführt, die andernfalls viele Male ausgeführt werden würden

  Vermeiden Sie dies, wenn Folgendes vorliegt:

  • Wenn Sie die Anzahl der Metriken wesentlich erhöhen
  • Wenn Sie mehr als drei Level implementieren
  • Wenn Sie die Komplexität der Implementierung erhöhen und die Verwaltung schwieriger wird
• Neuberechnungen
  • Vermeiden Sie massive Neuberechnungen als Teil des Normalbetriebs des Systems
  • Die Gründe für Neuberechnungen sind:
    • Rohdaten mit einem Zeitstempel in der Vergangenheit
    • Event-Besonderheit, die in der Vergangenheit liegende Rohdaten verändert
    • Korrekturen
    • Ausnahmen
    • Änderungen in den Business-Logik-Modulen
    • Änderungen in einem Vertrag
    • Wiederverwendbarkeit von Events - Events mit einem Zeitstempel in der Vergangenheit
    • Änderungen in der Ressourcenstruktur
  • Berücksichtigen Sie die Funktion zur Sperrung von Datenberechnung
• Business-Logik-Module
  • Die Business-Logik-Module sollten so geschrieben werden, dass sie nach einer kompletten Prüfung nicht mehr geändert werden müssen
  • Die Richtlinie ist: ein Modul entspricht einer generischen Logik
  • Die Business-Logik-Module, die sehr spezifisch sind, können weder für viele Metriken verwendet werden, noch fördern sie die Wiederverwendbarkeit von Code und Logik
  • Die Business-Logik-Module, die zu generisch sind, sind schwierig zu handhaben. Wenn ein Business-Logik-Modul viele komplexe Logiken implementiert, verursacht ein fester Wert in einem Durchgang (der von einem Teil der Metriken verwendet wird) zudem eine Neuberechnung aller Metriken
• Registrierung
  • Filtern Sie alle Events mithilfe der Registrierung. Wird das Filtern über den Code ausgeführt, hat dies einen großen Einfluss auf die Leistung
  • Einfache Gestaltung
  • Verwenden Sie bei einem Code, bei dem es sich nicht um die Registrierung selbst handelt, die Methoden "dispatcher.IsRunTimeMode" und "OnResourceStructureChange", insbesondere wenn es viele Ressourcenänderungen gibt
  • Vermeiden Sie es, die Methode "RegisterByEventType" zu verwenden
  • Verwenden Sie in Business-Logik-Modulen eine generische Form (von Vertragspartei, Service, Ressourcentyp) oder Parameter oder lassen Sie die Registrierung über die Benutzeroberfläche ausführen (bevorzugte Option für Event-Wiederverwendbarkeit)