Using Tuples effectively to store objects

Question

I have been working on some code and started using Tuple just to hold some data for a bit until some other functions are processed and then I use the Tuple in list to grab some information from it and send an email, for instance:

List<Tuple<Customer, Contact, Product>> tupleInfo = 
   new List<Tuple<Customer, Contact, Product>>();

Then i add the different objects to it by calling a method where I pass Customer, Contact and Product:

Tuple<Customer, Contact, Product> info = 
         new Tuple<Customer, Contact, Product>(myCustomer, myContact, myProduct);

info.Add(info);

At the end after I process all my stuff in other methods this list will endup with a maximum of 10 tuples that I then send to a method that sends an email, something like this:

private ActionResult SendEmails(List<Tuple<Customer, Contact, Product> list)
{
   ActionResult result = new ActionResult;
      foreach(Tuple<Customer, Contact, Product> info in list)
      {
             //Here i just grab some the information 
             //from each tuple, email, product,contact
             //contact info and customer info and send 
             //a personalized email, then do the same with the next records
      }
   return result;
}

My question is, how efficient is this, is it ok to use Tuples this way?, am I trading performance by using Tuples?

I am new using this so would like to know before I do it the wrong way.

No performance trade...but IMO tuples should primarily be declared and used close to each other; rarely exchanged between types in the same assembly, and almost never returned from an API consumed by others. This is especially true for types that may easily be mis-assigned to one another (e.g. Tuple...no compile time safety on which member is which, and the member names are just `Item1`, `Item2`, `Item3` so it is very easy to make a mistake). For my own sanity, I usually prefer internal classes. — Tim M., Oct 09 '13 at 05:04
Thanks for the input, based on your experience or knowledge. Would it be safe to say that in the way i am using it above, it's ok? — user710502, Oct 09 '13 at 05:06
Yes, it looks fine, since it looks like you are using it as an internal structure for convenience. You certainly won't lose any performance by using a tuple; there's [nothing special](http://stackoverflow.com/a/3089883/453277) (good or bad) about them in c#. — Tim M., Oct 09 '13 at 05:09
I think you're only sacrificing cleanliness and understandability. Those generics are really long and obscure - there's no explanation on why those 3 objects are being grouped. Something like class CustomerOrder (or at least alias) would be shorter, and more descriptive. — Mike Trusov, Oct 09 '13 at 05:10
@MikeTrusov: I don't think he's sacrificing any. Actually, like the OP says, this is gonna be short-lived. Declaring a custom class may bring an additional overhead. In this case, tuples is what I bet. (Mainly because, he is not gonna use this out of this context) — now he who must not be named., Oct 09 '13 at 05:13

score 1 · Answer 1 · answered Oct 09 '13 at 04:46

1

I don't think there is any performance drop associated with using Tuples. They are generic so it is as good as if you have written your own container class.

answered Oct 09 '13 at 04:46

Om Talsania

156
4

score 1 · Accepted Answer · answered Oct 09 '13 at 05:27

" started using Tuple just to hold some data for a bit "

If this is the reason, then there is no harm in using Tuples.

Generally, Tuples are used to hold some data where creating a class to represent the same information may seem meaningless.

You might want to do some business-logic, for which, creating a new class is an additional overhead and irrelevant.

But also remember one thing, it is not recommended to use a function whose return type is of TUPLE. This does not make any sense.

Eg, A function whose return type is EmailContent is more clearer than a function whose return type is a tuple with some signature like Tuple<string,int,bool,string,string>

Personally, I would use Tuples as some private member or for some scenarios where they have shorter lives and not-reusable components.

So, in this case, as long as you think, "holding some data for a bit", its perfectly ok.

Using Tuples effectively to store objects

2 Answers2