Il titolo dice la maggior parte. Ho trovato poche sorprendenti informazioni su questo. Ho una lunga esecuzione di cui l'utente vuole vedere il progresso (come in, articolo x di y processato). Devo anche essere in grado di mettere in pausa e interrompere l'operazione. (L'interruzione non esegue il rollback degli elementi già elaborati).
Il fatto è che non è che ogni elemento impieghi molto tempo per essere elaborato, è che di solito ci sono molti articoli. E quello che ho letto fino ad ora è che è un po 'un anti-pattern per mettere qualcosa come una coda nel DB. Al momento non ho alcun sistema di messaggistica e non ho mai lavorato con uno di questi.
Un'altra cosa che ho letto da qualche parte è che il reporting dei progressi è qualcosa che appartiene al livello dell'applicazione, ma non è entrato nei dettagli. Detto questo, quello che ho in mente è il seguente.
- La richiesta utente con l'elenco di elementi entra nel livello applicazione.
- Il livello applicazione ottiene alcune informazioni dal dominio necessario per elaborare gli elementi.
- Il livello applicazione passa gli articoli e le informazioni a qualche servizio di dominio (se l'implementazione di questo servizio appartiene al livello infrastruttura?)
- Questo servizio fa girare un thread di lavoro con callback sia per la segnalazione dei progressi che per metterla in pausa / arrestarla.
- Questo thread di lavoro elabora ogni elemento nel proprio UoW. Ciò significa che le informazioni sul dominio precedenti devono essere memorizzate in alcuni DTO.
- Poiché nulla è realmente persistente, il servizio dovrebbe essere singleton e thread safe
- Ogni volta che un utente richiede un rapporto sullo stato di avanzamento o desidera sospendere / interrompere l'operazione, il livello dell'applicazione chiederà il servizio.
Questa sarebbe una soluzione corretta? O sono almeno sulla strada giusta con questo? Soprattutto la parte singleton e thread safe rende tutto il complesso icky.