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

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 2

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

Answer 3

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 4

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.

Answer 5

Personally I use structs everywhere I need to store information, as long as it will not cause obvious performance issues. In most projects this is never, since the data is either directly mappable to an existing type or is larger than a reference (affecting the invariable LINQ queries and other manipulation). I find that structs are only viable when I can stick the data in an array and leave it there (modifying the variables directly in the array), the struct is rarely used, or the amount of data in the struct is less than 64 bits (ignoring struct overhead).

As it was explained to me, structs should be used only to store data and translate it from one form to another (ToString or ToArray converters).

Also, structs are more restrictive than classes with the primary differences:

• Structs are value types while classes are reference types. This means the whole struct instance is copied when it is assigned while only the memory address of a class instance is copied. Since most programs are 32bit or 64bit it is usually recommended to limit the size of the struct to prevent performance issues related to copying struct instances as compared to class instanceses. While this can be overcome by putting the structs in an array, this moves the structs to the heap (instead of stack). Also, using generics like List always returns a copy of the instance, since they use methods to access the values. See also the Struct Instances vs. Class Instances section in Objects (C# Programming Guide)
• Structs can be instantiated on the stack, while classes are always instantiated on the heap. This is controlled by the compiler and does not affect coding, though it may have a small performance benefit (which is rarely ever detectable).
• Within a struct declaration, fields cannot be initialized unless they are declared as const or static.
• A struct cannot declare a default constructor (a constructor without parameters) or a destructor.
• Unlike classes, structs can be instantiated without using a new operator.
• A struct cannot inherit from another struct or class, and it cannot be the base of a class.
• All structs inherit directly from System.ValueType, which inherits from System.Object while classes inherit from System.Object.
• A struct cannot be null (use the generic Nullable struct).