Approccio corretto per la creazione di un contratto API

Question

Approccio corretto per la creazione di un contratto API

#1 da (2 voti)

1

Ho bisogno di aiuto per quanto riguarda di seguito:

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. Puoi suggerire quale degli approcci sopra è 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'}}

e

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;}
}

e

class NewAccount{
public string Name{get; set;}
public string Password{get; set;}
public int Age{get; set;}
public OtherInfo OtherInfo{get; set;}
}

c# api-design

posta ATP 18.06.2015 - 18:34

fonte

1 risposta

Leggi altre domande sui tag c# api-design

puntatore condiviso o raw c ++ Devo installare automaticamente i moduli necessari?

score 2 · Answer 1

Ho intenzione di andare avanti e assumere alcune cose qui:

Stai cercando un pattern da applicare a più controller
Ci sono situazioni in cui una singola chiamata di azione può avere quantità variabili di dati inviati (nome / password garantiti ma a volte l'età e altre informazioni sono incluse).

Se le mie supposizioni sono corrette, suggerirei qualcosa al seguente.

public class Contact
{
    public String FirstName { get; set; }
    public String LastName { get; set; }
}

public class SpecialContact : Contact
{
    public String Title { get; set; }
}

public class AnotherSpecialContact : Contact
{
    public String Phone { get; set; }
}

public class ContactController
{
    public void MyAction(Contact contact)
    {
        // VALIDATE: Example validation provided.
        if (String.IsNullOrWhiteSpace(contact.FirstName)) { return; }
        if (String.IsNullOrWhiteSpace(contact.LastName)) { return; }

        if (contact is SpecialContact)
        {
            SpecialContact specialContact = contact as SpecialContact;
            // Do things SpecialContact specific.
        }
        else if (contact is AnotherSpecialContact)
        {
            AnotherSpecialContact anotherSpecialContact = contact as AnotherSpecialContact;
            // Do things AnotherSpecialContact specific.
        }

        // Do things Contact specific.
    }
}

Motivi per il mio suggerimento:

Tu, in qualità di sviluppatore dell'API, sai che i dati richiesti sono lì e puoi fare una semplice convalida per essere sicuro. Se si trattasse di un dizionario o di un tipo dinamico, dovresti eseguire la convalida del tipo in aggiunta alla normale convalida.
Come puoi vedere dagli esempi SpecialContact e AnotherSpecialContact , puoi estendere l'azione per gestire condizioni speciali in cui sono presenti dati extra. Se hai situazioni in cui sono presenti dati meno , significa che hai una classe base errata (cioè Contact in questo scenario).
( una sorta di ripetizione del # 1 ma ... ) stai usando un linguaggio tipizzato staticamente, quindi perché andare contro quello con dynamic ? L'unica volta che ho trovato la dinamica particolarmente utile è nei casi di Reflection, in qualsiasi altro momento ho trovato che è lo stesso o più lavoro delle alternative. Se pensi di aver bisogno di dynamic , dai un primo tentativo a Object .