Approccio corretto per la creazione del contratto API

2

Sto cercando di progettare un'API. Per creare i contratti di seguito sono i due approcci:

Metodo 1:

public class MyController
{
  public void MyAction1(Dictionary<string, dynamic> input)
  {
    //Use input like below
    //Read from input dictionary and apply minimal business logic if needed
    //And Call CustomDataProvider library with input object itself(DataProvider designed in such a way that it takes Dictionary and used values as procedure input. Dictionary key is same as procedure arguments.)
  }

  public void MyAction2(Dictionary<string, dynamic> input)
  {
    //Use input like below
    //Read from input dictionary and apply minimal business logic if needed
    //And Call CustomDataProvider library with input object itself(DataProvider designed in such a way that it takes Dictionary and used values as procedure input. Dictionary key is same as procedure arguments.)
  }
}

In questo caso non è necessario alcun contratto di dati.

Approccio 2:

public class MyController
{
    public void MyAction1(MyContractBusinessObject1 input)
    {
        //Do normal business logic processing using input object and call DBProvider by creating a dictionary from business object
    }
    public void MyAction2(MyContractBusinessObject2 input)
    {
        //Do normal business logic processing using input object and call DBProvider by creating a dictionary from business object
    }
}

In questo caso avremo diverse business class come contratto per diversi input di azione. Quale dei suddetti approcci è migliore e perché?

Lasciatemi fare un esempio. Supponiamo che le mie azioni stiano facendo il login e la creazione di nuovi account. Nel primo caso, l'input sarà

new Dictionary<string, dynamic>{
    {"Name","myname"},
    {"Passowrd",'mypassword'} 
}

new Dictionary<string, dynamic>{
    {"Name","myname"},
    {"Passowrd",'mypassword'},
    {"Age",myage},
    {"otherInfo",myotherinfo}
}

ma nell'approccio 2 l'input sarà

class Login{
    public string Name{get; set;}
    public string Password{get; set;}
}

class NewAccount{
    public string Name{get; set;}
    public string Password{get; set;}
    public int Age{get; set;}
    public OtherInfo OtherInfo{get; set;}
}
    
posta ATP 18.06.2015 - 18:45
fonte

2 risposte

1

In genere mi lamento su entrambi gli approcci. Se dovessi scegliere solo tra queste due scelte, probabilmente selezionerei quella completamente tipizzata perché mi dirà di più su ciò che sono tenuto a fornire solo osservando i tipi di firma e argomento del metodo. La soluzione Dictionary richiede che io dia un'occhiata alla documentazione dell'API o, peggio ancora, al codice dell'implementazione per scoprire quali valori sono significativi o richiesti nel dizionario. Il fatto è che hai un contratto di dati di qualche tipo, non importa quale sia il metodo che scegli. La differenza è la rilevabilità del contratto.

Sono un grande sostenitore nel rendere le cose il più semplici possibile se si fornisce un'API. Se il set di cose che devi passare all'API è piccolo per ogni metodo, in realtà è spesso più facile codificarlo rispetto a un'API quando tutti i valori richiesti vengono passati separatamente come: controller.Login(myname, mypassword) o %codice%. Quindi posso dire solo dalla firma del metodo che cosa dovrei passare. Alcuni degli IDE più fantasiosi possono persino riempire automaticamente i valori se ci sono valori ragionevoli nel contesto delle chiamate da indovinare. Raggrupperei gli argomenti in una struttura di qualche tipo solo se quella struttura è complessa o se viene utilizzata in tutto l'API per varie cose.

    
risposta data 07.08.2015 - 23:38
fonte
0

Quindi la domanda è: dovrei avere un singolo metodo che prende parametri generici, o molti metodi che prendono parametri specifici?

Interamente da te, ma nota: il metodo generico richiede molte convalide che potresti ottenere gratuitamente in parte utilizzando specifici tipi di parametri. Si noti inoltre che il metodo generico agirà come un broker, prendendo i tipi generici e traducendoli in tipi specifici per passare alle funzioni di supporto in ogni caso (simile a come un server Web ha una singola routine che accetta richieste, le analizza e le passa su una routine specifica per la pagina richiesta).

È del tutto soggettivo, ho visto entrambi gli stili usati in circostanze diverse, ed entrambi funzionano.

    
risposta data 08.07.2015 - 10:12
fonte

Leggi altre domande sui tag