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).
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.
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.
We can use a Dictionary as well, and in my own opinion works better.
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.
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
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.