2015-12-16 21 views
7

Vedere questo esempio di classe statica di seguito.Il modo migliore per refactoring questa classe statica in C#?

public static class BackgroundTaskExecuter 
{ 
    public static void MethodA() 
    { 
     using (var service = IocManager.Instance.ResolveAsDisposable<IServiceA>()) 
     { 
      service.Object.MethodA(); 
     } 
    } 

    public static void MethodB() 
    { 
     using (var service = IocManager.Instance.ResolveAsDisposable<IServiceB>()) 
     { 
      service.Object.MethodB(); 
     } 
    } 

    public static void MethodC() 
    { 
     using (var service = IocManager.Instance.ResolveAsDisposable<IServiceC>()) 
     { 
      service.Object.MethodC(); 
     } 
    } 
} 

Come potete vedere, ho tre metodi. MethodA, MethodB, e MethodC che corrispondono a tre differenti interfacce IServiceA, IServiceB e IServiceC

La ragione per cui sto facendo questo è perché sto usando Hangfire.io con quadro aspnetboilerplate e in Hangfire, un compito di fondo non ha HttpContext dalla normale iniezione di dipendenza. La creazione di una classe statica che avvolge le mie chiamate laddove risolvo manualmente sembra aggirarla.

Uso assomiglia a questo:

BackgroundJob.Enqueue(() => BackgroundTaskExecuter.MethodA()); 

Per ora, ho solo una o due operazioni in background nella mia web app, ma in teoria io possa avere molto di più in futuro, e mentre è mantenibile ora, è diventerà brutto alla fine se tengo questo approccio.

C'è un modo migliore per farlo/refactarlo? Forse un modello di fabbrica o qualcosa di simile?

Grazie.

+1

L'esempio @RuneFS/ipotetico/codice MCVE è off-topic in [codereview.se]. Si prega di consultare [Una guida alla revisione del codice per gli utenti SO] (http://meta.codereview.stackexchange.com/questions/5777/a-guide-to-code-review-for-stack-overflow-users). –

+0

Direi che questa domanda segue effettivamente l'ambito definito nel Centro assistenza. –

risposta

6

Farei l'involucro statico generico e semplice. Lascia che esca un singolo metodo che risolve il servizio e lo consumi tramite l'istruzione using, consentendo al chiamante di richiamare l'istanza passata nello Action<T>.

Fonte

public static class BackgroundTaskExecuter 
{ 
    public static void ResolveAndConsume<T>(Action<T> consumeService) 
    { 
     // Consider applying constraint to the <T> to 
     // match the constraint of ResolveAsDisposable<T> 
     using (var service = IocManager.Instance.ResolveAsDisposable<T>()) 
     { 
      consumeService(service); 
     } 
    } 
} 

Esempio di utilizzo

BackgroundJob.Enqueue(() => 
    BackgroundTaskExecuter.ResolveAndConsume<IServiceA>(serviceA => serviceA.MethodA())); 

Con quanto sopra si potrebbe quindi risolvere e consumare un'implementazione del servizio e chiamare la sua funzionalità, se lo desideri.

+1

La domanda è: tutti questi servizi hanno un'interfaccia comune, suppongo che non ci sia alcuna indicazione di quello –

+1

Ho ipotizzato che 'T' avrebbe un vincolo di' IService', ma non è necessario. Dovrebbe solo seguire il vincolo del metodo 'ResolveAsDisposable '. –

Problemi correlati