Come gestire i thread in background di lunga esecuzione e segnalare i progressi con DDD

5

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.

    
posta dvdvorle 12.10.2012 - 08:23
fonte

1 risposta

1

Questi tipi di problemi operativi sono di responsabilità del livello applicativo e in quanto tali sono agnostici del DDD. Il livello dell'applicazione delega al livello del dominio che può essere implementato utilizzando DDD. È atipico per un servizio di dominio far ruotare i thread di lavoro e gestire lo stato di elaborazione. Invece, dovrebbe concentrarsi sull'implementazione della logica di dominio che non appartiene naturalmente a un oggetto aggregato, di entità o valore. La gestione dei thread e dello stato di elaborazione deve essere gestita dal livello dell'applicazione in quanto è un problema operativo, non un problema di dominio. Esistono diversi modi per implementare processi a lungo termine con informazioni sullo stato di avanzamento. Utilizzare i thread all'interno di un AppDomain è solo un modo per andare. Ad esempio, se è richiesta la tolleranza di errore e la distribuzione, è meglio posizionare gli elementi di lavoro in una coda duratura e disporre di un gestore di messaggi che elabora tali messaggi delegando al livello di dominio. Tale implementazione è descritta in Richiesta / Riconoscimento / Sondaggio Con ASP.NET WebAPI e NServiceBus . Indipendentemente dall'implementazione di questa responsabilità del livello applicativo, il dominio rimane lo stesso.

    
risposta data 13.10.2012 - 19:35
fonte

Leggi altre domande sui tag