utilizzando il proxy Web API

0

Ho un'applicazione MVC e una web API. L'API Web contiene tutta la logica aziendale e il controller mvc ha solo logica ui.

Voglio creare un proxy web API ma non so se sia una buona idea.

Con il proxy web api Il controller è disaccoppiato dal nome dell'azione nella web api e dai verbi e dto utilizzati nella web api. Con una riga di codice, chiamo la web api e ricevo una risposta. Se voglio chiamare l'azione in molti controller, devo usare solo una riga di codice e se c'è una modifica, cambio solo il proxy.

Senza proxy È più semplice, perché nel controller uso httpclient per chiamare la web api, ma se vuoi chiamare la stessa azione da molti controller mvc, devo replicare il codice.

Il proxy che voglio creare è registrato con autofac nell'asax globale e nel costruttore di controller inietto il proxy.

Per esempio se voglio un elenco di prople, con proxy devo Registrare il PeopleProxy nell'asax globale crea il costruttore del controller mvc con IProxyPeople

private IProxyPeople peopleProxy;
MyController(IProxyPeople peopleProxy){
    this.peopleProxy = peopleProxy;
}

Chiama con un codice come

peopleProxy.GetPeople()

Senza proxy

Io chiamo l'apri web direttamente dal controller mvc con un codice come

using (HttpClient client = CreateHttpClient())
{
    var peoples;
    try
    {
        HttpResponseMessage result = client.GetAsync("api/People").Result;
        peoples = result.Content.ReadAsAsync<List<People>>().Result;
    }
    catch (Exception exc)
    {
         CLog.LogError(exc);
    }                   
}

Qualcuno pensa che sia meglio chiamare la web api direttamente dal controller perché è più semplice di creare il proxy e non ci sono overhead con autofac. Dovrebbe essere una buona idea creare un proxy web API?

    
posta user3401335 11.07.2017 - 17:47
fonte

2 risposte

3

Il servizio (proxy) non si limita ad astrarre l'endpoint, ma incapsula anche l'analisi della risposta e la logica di gestione degli errori. È una buona astrazione.

È la mia esperienza che le persone che sostengono il codice inlining e l'astrazione shun non hanno ancora raccolto abbastanza esperienza per sapere in che modo questo comportamento li brucerà in seguito. Fai a modo tuo

    
risposta data 11.07.2017 - 17:51
fonte
3

Dovresti assolutamente seguire il percorso del proxy, per diversi motivi.

  1. Non dovrai ripeterti (vedi DRY ).

  2. manterrai una migliore separazione dei dubbi .

  3. Sarai in grado di testare separatamente il proxy o scrivere test di integrazione automatici per testare il proxy.

  4. Puoi stubare il proxy e testare il sito web in modo indipendente, se ad esempio lo stai eseguendo in un laboratorio di sviluppo senza accesso al servizio.

  5. Se cambi il modo in cui funziona il proxy (ad esempio se un giorno il servizio inizia a richiedere i certificati client) dovrai solo aggiornarlo in un posto nel codice.

  6. Se desideri aggiungere funzionalità aggiuntive alla chiamata di servizio, ad es. caching, avrai un posto dove metterlo.

risposta data 12.07.2017 - 03:02
fonte

Leggi altre domande sui tag