Working with Tuples in C# and reduce the clutter in your code by avoiding unnecessary POCO classes

I am a Dynamics 365 solution architect and one of my job responsibility is to perform lots and lots of code review. If you are not into Dynamics 365 but just came here to learn Tuples, well don’t worry about it. This article is about Tuple’s and how it can reduce the use the unnecessary classes in code.

But what is a POCO class. Well POCO stands for Plain Old CLR Objects. POCO classes are classes which does not depend on framework base code and you just create them to temporarily hold list of data for further insert/ update/ delete and whatever operations you desire.

Let’s take a scenario here. I am a Dynamics 365 fan, so I take an example right out of there.

Let’s take an example where I want to get the List of accounts along with Primary contact name, email and id. Contact and parent (1:N).

image

Observe the code in the above screenshot. You don’t need to be aware of the query construct. Pay attention to the class AccountDetails. The class we just created to hold multiple properties of varying data type and return it to the calling function. Below is the class.

image

That’s where Tuple come in. You can create a Tuple as simple as this.

var tuple = Tuple.Create<int, string, bool>(1, “Lorem ipsum”, true);

Now let’s see how we can clean up the the same code above.

static List<Tuple<string, int, string, Guid>> GetAccountDetails(CrmServiceClient client)
       {
          List<Tuple<string, string, string, string>> accDetails = new List<Tuple<string, int, string, Guid>>();

         var fetch = @”<put your query here>”;

         var results = client.RetrieveMultiple(new FetchExpression(fetch));

         foreach(var record in results.Entities)
          {
             var tuple = Tuple.Create<Tuple<string, int, string, Guid>>(“<acc name>”, < accountnumber >, “<contactemail>”, “<Contactguid>”);
             accDetails.Add(tuple);
          }

         return accDetails;
       }

The custom class is gone altogether.

Now see how you can access the return values.

var results = GetAccountDetails(client);

 

         foreach(var result in results)
          {
             var accName = result.Item1;
             var accNumber = result.Item2;
             var contactEmail = result.Item3;
             var contactid = result.Item4
          }

Simple and easy. And now imagine how much you can get rid of creating classes and using Tuples.

And if you are in Dynamics 365 and writing plugin and workflow code a lot, may be it’s time to look back and see if it can be cleaned up.

Hope this helps!

Debajit Dutta

Business Solutions MVP

For training and consulting, please write to us at info@xrmforyou.com


Discover more from Debajit's Power Apps & Dynamics 365 Blog

Subscribe to get the latest posts sent to your email.

4 thoughts on “Working with Tuples in C# and reduce the clutter in your code by avoiding unnecessary POCO classes”

  1. Hi Debajit,
    Agree with the lesser lines of code with the use of Tuples.
    But wouldn’t it make the code less readable too? Besides, every time I need to reference data from the List of tuples, I’ll need to remember, Item 1 was account number and Item 4 was Contact Id. With POCOs it’s understandable from the variable name itself.

    1. Hi Hufeza,
      Can’t agree more and thanks for reading my blog. And I would say everything have their fare share of strengths and weakness. I feel Tuples would be more useful where there is requirement to create and return runtime objects multiple times within an operation. However is a construct is to be re-used, then as you told POCO classes would be the best.
      Cheers!
      Debajit

      1. Yes, agree. I guess it’s on the developers to be aware of what options are available to them and chose the best based on what the situation demands.
        Thanks for the nice blog article explaining the Tuple option.

Comments are closed.

Discover more from Debajit's Power Apps & Dynamics 365 Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading