Should I use a structure instead of a class to hold string only data in C#?

Question

C# question.
Say I have a customers class that has a bunch of props for storing string only data such as name postal data and phone numbers.

I don't use this entity for ORM as I'm only adding it to some type of collection for use during app life cycle. Additionally I don't need to add any entity specific methods to it or persist the data to xml or database, or even to a webservice.

Is it better to make this a struct rather than a class? or no benefit? Also side question, should I make the collection Customers, a list structure?

Be harsh, please critique.. :)

 struct customer
    {
        private string name;

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

    }

struct Customers<List>
{
    private customer cust;

    public customer Cust
    {
        get { return cust; }
        set { cust = value; }
    }

}

Answer 1

Unless you have identified specific reasons for using a struct, use a class.

Update: due to @Dmitry Lobanov: Eric Lippert's post: The Truth About Value Types

Structs vs. Classes

Structs may seem similar to classes, but there are important differences that you should be aware of. First of all, classes are reference types and structs are value types. By using structs, you can create objects that behave like the built-in types and enjoy their benefits as well.

Heap or Stack?

When you call the New operator on a class, it will be allocated on the heap. However, when you instantiate a struct, it can be created on the stack. This will yield performance gains. Also, you will not be dealing with references to an instance of a struct as you would with classes. You will be working directly with the struct instance. Because of this, when passing a struct to a method, it's passed by value instead of as a reference.

Ref.

Answer 2

I suppose you could look at When to use struct in C#?

Answer 3

MSDN article (Classes and Structs)

Answer 4

I can't see any value in making the customer a struct. The string fields will all be reference types, so you might as well make the whole thing a reference type (ie. class).

I'd be inclined to use one of the built-in collection types rather than create my on type for Customers. Something like:

List<Customer> Customers = new List<Customer>();

Answer 5

Be aware of the mis leading fact that

Value type is more faster rather than reference types.

Actually , think about refernces when you pass reference type , you are passing a pointer to an

existing object while passing value type , you are actually passing a whole new object with identical value.

Answer 6

For what it's worth, I would never use structs because I so very rarely have a need to provide a data only structure that doesn't have some sort of associated behaviour (validators, formatters, etc...).

The one thing that I do like about the basic concept of a "struct" is that it represents a storage system at it's most basic, and therefore should avoid the need to write all those pernickity custom getters and setters and all that sort of stuff... but then again, we now have those lovely auto-properties which effectively achieve the same result from purely a coding perspective, and while the YAGNI nazi in me might say to use the struct because it is meant to be simple, the realist in me knows that I will inevitably want to change the struct to a class anyway, so why not simply implement the class from the beginning and be done with the matter! ;-)

As for the argument of performance, and other benefits... ask yourself the question "does this really matter". If you're writing a serious real-time system... perhaps you want to be using another tool. If you're simply passing around some data, you've likely got oodles of processing croutons at your disposal, and your killer algorithm might not really need to worry about the nano-second difference it's going to make.