Guida all'implementazione › Esempi di case study › Esempi di scrittura di business logic efficace

Esempi di scrittura di business logic efficace

Si consigliano le best practice di scrittura per una business logic efficace in relazione ai seguenti oggetti:

• Metriche di gruppo
  • Durante la valutazione del volume di sistema, conteggiare una metrica di gruppo come il numero di elementi nella metrica e tenere presente che tutto viene moltiplicato.
  • Il ricalcolo di un elemento di gruppo comporta il ricalcolo dell'intero gruppo. Pertanto è necessario tenerne conto durante la pianificazione del raggruppamento, del modo in cui gli adapter vengono configurati e durante le modifiche alla struttura delle risorse
  • Gli stessi eventi di dati non elaborati che rientrano in diversi elementi di gruppo hanno un elevato costo delle prestazioni (cambio di contesto)
• Variabili globali
  • Ottenere i parametri e i valori di attributo in ciascun punto del codice in cui sono necessari. Evitare di tenerli nella variabile globale, in particolare nelle metriche di gruppo (aumenta la dimensione degli stati)
  • Evitare la logica che elabora mappe di grandi dimensioni. Al contrario, elaborare ogni evento con il metodo OnXXEvent
  • Rimuovere gli elementi dalle mappe appena possibile. Ad esempio, quando un ticket viene chiuso e non al termine del periodo
• Modelli di progettazione

  Il pacchetto del contenuto predefinito contiene diversi modelli di progettazione per scenari comuni. L'utilizzo di questi modelli di progettazione consente di migliorare le prestazioni

• Funzionalità integrata

  ACE dispone di una funzionalità integrata e di strumenti per diversi scopi, come indicato di seguito:

  • Funzionalità del periodo di applicazione
    • NetTime
    • IsWithinTimeslot
  • Ora di eventi
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Oggetto di contesto
    • Contiene molti metodi distinti a seconda dell'ambiente
    • Utilizzare questi metodi ed evitare Safe ODBC
• Output di business logic

  Mantenere la struttura in T_SLALOM_OUTPUTS. Ciò significa che se si dispone di più tabelle logiche in T_SLALOM_OUTPUTS con una struttura simile, è molto utile inserire campi logici analoghi nello stesso campo fisico. Viene così consentita una facile indicizzazione per migliorare le prestazioni dei report

• Riusabilità dell'evento

  Da impiegare quando:

  • Diverse metriche eseguono il calcolo di prima fase, di per sé richiesto per il contratto, e inviano gli eventi a una metrica di riepilogo che calcola il risultato (ad esempio, il calcolo finanziario, KPI di livello elevato)
  • Una singola metrica esegue un'aggregazione preliminare sui dati non elaborati e invia gli eventi a molte altre metriche. Ammessa quando la metrica invia meno eventi rispetto a quelli che riceve o esegue calcoli significativi che altrimenti vengono eseguiti più volte

  Da evitare quando:

  • Aumenta significativamente il numero di metriche
  • Vengono implementati più di tre livelli
  • La complessità dell'implementazione aumenta e la manutenzione diventa più difficile
• Nuovi calcoli
  • Evitare ricalcoli pesanti come parte del normale funzionamento del sistema
  • I motivi per eseguire nuovi calcoli sono:
    • Dati non elaborati con data/ora nel passato
    • Univocità dell'evento che modifiche i dati non elaborati nel passato
    • Correzioni
    • Eccezioni
    • Modifiche nei moduli di business logic
    • Modifiche apportate a un contratto
    • Eventi di riusabilità dell'evento con data/ora nel passato
    • Modifiche nella struttura delle risorse
  • Prendere in considerazione l'utilizzo della funzionalità di blocco dei dati calcolati
• Moduli di business logic
  • È necessario scrivere i moduli di business logic in modo che, una volta completata la revisione, non debbano essere modificati
  • La linea guida è: un modulo equivale a una logica generica
  • I moduli di business logic molto specifici non possono essere utili a molte metriche e non favoriscono il codice né la riusabilità della logica
  • I moduli di business logic troppo generici sono difficili da gestire. Inoltre, se un modulo di business logic implementa molte logiche complesse, la correzione in un flusso (utilizzata da parte delle metriche) comporta il ricalcolo di tutte le metriche
• Registrazione
  • Eseguire il filtraggio completo degli eventi mediante la registrazione. Lasciando la funzione di filtro al codice comporta un notevole impatto sulle prestazioni
  • Semplificare il processo
  • Per il codice che non è la registrazione stessa, utilizzare i metodi dispatcher.IsRunTimeMode e OnResourceStructureChange, in particolare quando sono presenti più modifiche nelle risorse
  • Evitare l'utilizzo del metodo RegisterByEventType
  • Nei moduli di business logic, utilizzare un modulo generico (per contraente, servizio, tipo di risorsa) oppure utilizzare i parametri o lasciare l'esecuzione della registrazione mediante l'interfaccia utente (opzione consigliata per la riusabilità dell'evento)