Coda di lavori in stati diversi e con diversi servizi in giro

2

Ho bisogno di progettare una "coda" di lavori (in un'applicazione molto orientata all'interfaccia utente) che possa essere eseguita da un utente e ho bisogno di altri pensieri per scegliere l'approccio ottimale da zero.

I miei lavori possono essere in stati diversi (importati, inviati da elswhere, creati dall'utente, anche solo per essere simulati con i loro progressi registrati importati - seguendo un flusso di lavoro diverso), ecc.

Pertanto possono anche passare attraverso i diversi stati del loro ciclo di vita, come essere creati, in esecuzione, in pausa, convalidati o modificati da un utente (in caso di parametri di lavoro non validi), importati o anche in fase di cancellazione (a almeno per la registrazione o il controllo).

Per questo motivo, tutti i lavori devono avere il loro stato in ogni punto del tempo e devono essere gestiti in qualche modo da una logica comune.

Esistono anche regole di dominio e applicazione, che solo uno può essere in esecuzione / arrestato / param modificato in uno stato temporale, ecc ...

La mia domanda principale è se implementare una sorta di controllore monolitico per tutti gli stati in cui può rispondere alle guardie di ciascuno di essi (può / non può passare ad altro stato) per tutti gli stati e può chiamare azioni (altri servizi su di loro, o se implementare macchine di stato all'interno dei processi stessi e in qualche modo chiamare da sé i servizi e la logica condizionale correlata (cancellami / modificami e così via).

Ho anche bisogno di legarlo strettamente all'interfaccia utente, in modo da avere un elenco di attività con gli stati visibili per l'utente ma ho anche la separazione delle preoccupazioni (lavoro stesso come oggetto di dominio dei parametri - non stati , Interfaccia utente).

Questa è solo una breve descrizione del mio problema principale, quindi potrei aggiornare i requisiti come suggerimento o altre domande a cui ho dimenticato di arrivare.

    
posta JankoHrasko 27.07.2014 - 01:55
fonte

1 risposta

1

Avrei una classe BaseJob che conterrà proprietà e funzionalità di base / condivise. Può essere una classe abstract o solo una classe base semplice, a seconda della situazione. Se tutti i lavori e gli stati hanno comportamenti simili, la classe base può agire come un controller ed essere astratta.

Avrei anche State in ogni Job o potrebbe essere il BaseJob può aspettarsi una sorta di BaseState o GenericState . Il State può contenere la logica per lo stato successivo o potrebbe anche chiamare qualche servizio per quello, ma isolare quella logica in quell'oggetto.

Per UI avrai comunque bisogno di una sorta di viewmodel , credo che manterrà il tuo livello aziendale isolato e contenga più preoccupazioni relative all'interfaccia utente / MVVM.

    
risposta data 27.07.2014 - 04:51
fonte