File flat per eventi e allarmi

Naviga le tue risposte
0

Quindi sto lavorando a un progetto che mi è stato presentato un anno fa. Una delle caratteristiche del progetto comporta l'allarme degli utenti quando determinati eventi vengono attivati. C'è anche un registro di questi eventi. Per prima cosa devi capire questo:

  1. Non tutti gli avvisi generano registri eventi
  2. Gli eventi possono essere registrati senza generare allarmi.

Il design di questo comporta file flat che contengono una serie di informazioni sugli eventi e gli allarmi. Questo include tutto da dove vengono inviati gli allarmi, i livelli di priorità, ecc.

Ciò che accade nel codice è quando un evento si innesca, invia un messaggio con un gruppo di dati ad esso collegato a un processo che legge i file flat, sostituisce i dati in modo appropriato e quindi lo instrada.

La mia domanda è questa:

È normale progettazione salvare tutte queste informazioni al di fuori del codice. Stiamo incontrando problemi durante la distribuzione perché dobbiamo assicurarci che i file flat e il codice siano sincronizzati. Ha creato alcuni incubi per la risoluzione dei problemi, e onestamente sembra più una seccatura, quindi è sufficiente avere una lezione dedicata a questa roba e spedirla con il codice.

    
posta Triplell89 28.05.2015 - 20:22
fonte

2 risposte

1

Quindi, come comprendo la tua domanda, salvi la configurazione degli allarmi / eventi in un file.

È piuttosto normale avere file di configurazione. ma sospetto dal tono della domanda che tu abbia compiuto un ulteriore passo avanti in questo caso e abbia un sistema 'generico' che puoi usare per fare 'qualsiasi' allarme / evento e che la configurazione abbia sia configurazione che elementi di logica per esso.

Penso che sia una costante tentazione di scrivere sistemi in questo modo. Ovviamente si desidera un sistema flessibile che gli utenti possano configurare senza riscrivere il codice.

Tuttavia, a mio avviso, può essere una cattiva pratica. Man mano che un sistema si evolve e le funzionalità vengono aggiunte, puoi scegliere di aggiungerle alla configurazione o al codice. Più funzioni aggiungi come opzioni configurabili, più come un linguaggio di programmazione diventa la tua configurazione! Si può finire con un linguaggio di programmazione / configurazione molto approssimativo, con molti trucchi non documentati e file non verificati.

Non è tanto sbagliato scrivere un nuovo linguaggio di programmazione, ma è comunque necessario applicare il normale rigore di documentazione, controllo delle versioni, distribuzioni, test ecc. che normalmente si farebbe con una nuova versione del codice.

Inoltre aggiungerei che se si crea un sistema di allarme / evento generico, che non è specifico per la propria attività. Quindi probabilmente lo avresti acquistato dallo scaffale per un importo molto inferiore a quello necessario per scriverlo.

    
risposta data 06.10.2015 - 00:18
fonte
1

Is it normal design to save all this information outside of the code.

Penso che sia perfettamente normale. Puoi usare Observable pattern per gestire la distribuzione degli eventi e archiviare la sua configurazione (abbonamenti effettivi) all'interno, ad esempio, del database.

Non rispetto per l'archiviazione delle informazioni in file semplici. È difficile modificarli atomicamente e non sono pensati per memorizzare dati di reale complessità. Utilizza almeno il database SQLite.

    
risposta data 07.06.2015 - 19:32
fonte

Leggi altre domande sui tag

Un metodo di confronto dovrebbe mai restituire lo stesso tipo di quello che sta confrontando? Perché è più veloce compattare una porzione dell'heap gestito rispetto all'intero heap?