2

I am trying to design an API. For creating contracts below are the two approaches:

Approach 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 this case we don't need data contract at all.


Approach 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 this case we'll have different business classes as contract for different action inputs. Which of the above approaches is better and why?

Let me give an example. Suppose My actions are doing login and new account creation. In first case input will be

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

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

but in approach 2 input will be

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

migrated from stackoverflow.com Jul 8 '15 at 7:33

This question came from our site for professional and enthusiast programmers.

  • 1
    In the first approach, will the server-side code be peeking into the dictionaries and making assumptions/requirements about what they contain? If so, other than losing all compile-time type safety, what's the benefit over the second approach? – David Jun 18 '15 at 16:52
  • @David: I have updated the question with an example. While using dictionary we are getting below advantage: In case we don't have any business logic for any particular action and it is only propagating the dictionary received to CustomDataProvider, if we have to add some parameter in input then all we have to change is sql procedure and no change is required is api. – ATP Jun 18 '15 at 17:21
  • 1
    @AshutoshPandey: If the new added field is required, it is a change to the published API regardless of how it's implemented. If it's not required, then either approach would work the same to any external observer. There really isn't much of a difference at the published API level. – David Jun 18 '15 at 17:25
1

I generally grumble about both approaches. If I had to choose between only those two choices I would probably pick the fully typed one because it will tell me more about what I am required to provide just by looking at the method signature and argument types. The Dictionary solution requires me to go look at API documentation or worse yet the implementation's code to find out what values are meaningful or required in the dictionary. The thing is, you do have a data contract of some kind no matter which method you choose. The difference is how discoverable that contract is.

I am a big believer in making things as easy as possible if you are providing an API. If the set of things you are required to pass to the API is small for each method it is actually often easier to code against an API when all required values are passed separately like: controller.Login(myname, mypassword) or controller.NewAccount(myname, mypassword, myage, myotherinfo). Then I can tell from just the method signature what I am expected to pass. Some of the fanciest IDEs will even autofill the values if there are reasonable values in the calling context to guess. I would only bundle up the arguments into a structure of some kind if that structure is complex or if it gets used all over the API for various things.

0

So the question is: should I have a single method that takes generic parameters, or many methods that take specific parameters?

Entirely up to you, but note: the generic method requires much validation that you'd partially get for free by using specific parameter types. Note also that the generic method will be acting as a broker, taking the generic types and translating them into specific types to pass to helper functions anyway (similar to how a web server has a single routine that accepts requests, parses them, and passes them on to a routine specific to the requested page).

Its entirely subjective, I've seen both styles used in different circumstances, and both work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.