utilizzo del modello di progettazione del gestore richieste

Question

utilizzo del modello di progettazione del gestore richieste

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Ho osservato molti esempi in C # in cui viene seguito il seguente schema, ma non sono sicuro di come questo ci aiuterà a lungo termine

L'approccio tipico che ho visto è

crea un'interfaccia
implementa l'interfaccia
crea un gestore
gestore chiamate

Sarebbe davvero bello se qualcuno potesse dirmi come questo approccio aiuterà nel mondo reale senario

interfaccia IRestService per varie richieste web

public interface IRestService
    {
        Task<List<TodoItem>> RefreshDataAsync ();

        Task SaveTodoItemAsync (TodoItem item, bool isNewItem);

        Task DeleteTodoItemAsync (string id);
    }

Codice che implementa l'interfaccia IRestService

public class RestService : IRestService
{
    HttpClient client;

    public List<TodoItem> Items { get; private set; }

    public RestService ()
    {
        var authData = string.Format("{0}:{1}", Constants.Username, Constants.Password);
        var authHeaderValue = Convert.ToBase64String(Encoding.UTF8.GetBytes(authData));

        client = new HttpClient ();
        client.MaxResponseContentBufferSize = 256000;
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", authHeaderValue);
    }

    public async Task<List<TodoItem>> RefreshDataAsync ()
    {


    }

    public async Task SaveTodoItemAsync (TodoItem item, bool isNewItem = false)
    {

    }

    public async Task DeleteTodoItemAsync (string id)
    {

    }
}

Manager che chiama i metodi implementati

public class TodoItemManager
{
    IRestService restService;

    public TodoItemManager (IRestService service)
    {
        restService = service;
    }

    public Task<List<TodoItem>> GetTasksAsync ()
    {
        return restService.RefreshDataAsync (); 
    }

    public Task SaveTaskAsync (TodoItem item, bool isNewItem = false)
    {
        return restService.SaveTodoItemAsync (item, isNewItem);
    }

    public Task DeleteTaskAsync (TodoItem item)
    {
        return restService.DeleteTodoItemAsync (item.ID);
    }
}

per eseguire la richiesta

TodoManager = new TodoItemManager (new RestService ()); 
TodoManager.GetTasksAsync ();

alcune domande mi vengono in mente

perché abbiamo bisogno di un manager perché non possiamo usare solo RestService
se un giorno ho bisogno di sviluppare un modulo per recuperare i dati relativi ai contatti dal server allora ho bisogno di aggiungere metodi in IRestServie a addContact() , deleteContact() , getContact()

c# design-patterns

posta Hunt 16.01.2018 - 13:27

fonte

3 risposte

3

Un'interfaccia è pensata per nascondere i dettagli delle classi concrete che li implementano. Ciò significa che puoi digitare hint sull'interfaccia e non preoccuparti di quale oggetto concreto sta effettivamente eseguendo i metodi.

Un "servizio REST" sembra essere un candidato scadente per un'interfaccia, poiché REST stesso è un dettaglio di implementazione . Invece, dovrebbe esserci probabilmente un'interfaccia "lista di cose da fare" e quindi implementazioni: una classe che carica un elenco di cose da un servizio REST, una classe che carica un elenco di cose da fare dal file system e così via.

Se hai seguito questo approccio, e poi dipendendo dall'interfaccia, a mio parere elimina la necessità di un gestore, poiché avrai un'iniezione di dipendenza cablata da qualche parte che dice "Quando richiedo un'istanza di ITodoList , dammi un'istanza di RestBasedTodoList ".

risposta data 16.01.2018 - 14:19

fonte

0

La tua denominazione non sembra corretta.

IRestService è l'interfaccia di un servizio che chiami

il tuo RestService , è in realtà un client per quel servizio. quindi chiamalo uno

RestServiceClient : IRestService

allora il tuo Manager è un'applicazione che usa il servizio per fare cose. Normalmente questo richiederà più di un singolo servizio e sarà un Controller , o un ViewModel o qualcosa

public class TodoItemController
{
    IRestService client;
    IAnotherService client2;

    public void DoSomething()
    {
        var x = client.DoThing();
        client2.DoSomethingElse(x/2);
        MessageBox("I DID IT!");
    }
}

Forse, hai solo molti casi semplici in cui la logica viene semplicemente tramandata. In questi casi, sì, penso che puoi tranquillamente saltare la classe Manager . Ma forse stai mettendo la logica da qualche altra parte e in realtà hai bisogno di spostarlo sul livello corretto?

risposta data 16.01.2018 - 18:20

fonte

Leggi altre domande sui tag c# design-patterns

Come si chiama un processo che non verrà completato? [chiuso] Creazione di un portale Web per accedere a più database (sicurezza e best practice?)

score 1 · Accepted Answer

Perché abbiamo bisogno di un manager?

Il gestore rappresenta la logica aziendale che circonda la chiamata di un servizio di riposo. Il tuo esempio è stato un po 'troppo semplice per capire perché un manager può essere utile. Considera il caso d'uso in cui devi occuparti di più servizi REST. Ma è qui che puoi gestire la pre-validazione dei dati, effettuare una chiamata successiva se addContact ha esito positivo o negativo, ecc.

Perché non utilizzare `RestService` Direttamente?

Test. Verifica la logica di business (gestore) separatamente dal tuo servizio di assistenza.

Controllo delle versioni. Rende più semplice la sostituzione dell'implementazione di RestService quando l'implementazione deve essere modificata a causa dei vincoli di versione.

Contenimento. Il motivo principale è quello di contenere la logica aziendale separatamente dalla logica di presentazione. Riduce al minimo l'impatto se la nuova versione di RestService provoca alcuni passaggi aggiuntivi che devi mantenere nel codice. Mantenendo un'interfaccia hai il controllo sullo stesso (il tuo manager) puoi contenere le modifiche richieste da una modifica in un'interfaccia su cui non hai realmente il controllo (servizio di riposo).

Recupero di nuovi dati da un nuovo servizio

IRestService è un brutto nome per questo motivo. Avresti interfacce separate per ogni servizio REST che dovevi contattare. Ad esempio, avresti un ITodoRestService e un IContactRestService o qualcosa del genere. Se il tuo TodoManager aveva bisogno di usare entrambi (cioè associare elementi di todo a un contatto), avrebbe un riferimento a entrambi. Che poi ti riporta al motivo per cui abbiamo bisogno di un manager in primo luogo.

utilizzo del modello di progettazione del gestore richieste

3 risposte

Perché abbiamo bisogno di un manager?

Perché non utilizzare RestService Direttamente?

Recupero di nuovi dati da un nuovo servizio

Perché non utilizzare `RestService` Direttamente?