My inclination would be to use a simple struct with public fields (not properties). The beautiful thing about such structs is that they all behave identically aside from the names and types of their fields. Given an array MyPeople[]
of a struct Person
with exposed field Name
, one can know that MyPeople[0].Name = "George";
will have no effect upon MyPeople[1].Name
. By contrast, if Person
were an otherwise-identical class, there would be no such guarantee. Even if Person
were a struct with a read-write property Name
, one wouldn't know without looking at its definition whether or not the property would actually behave like a struct field, or whether it would access something stored in a class object.
Note that the reasons which might cause one to generally favor properties over fields do not apply to simple structs. If an object Fred
holds a field George
of a class type, and has exposed to the outside world a reference to the object referred to thereby, the only way Fred
can know that George
's properties won't change without its knowledge or consent is if the code for class George
won't let those properties change without, at minimum, letting Fred
know about (in many cases, it's simplest for George
to simply promise that it won't let its properties change under any circumstances). By contrast, if Fred
holds a field Ronald
of an exposed-field struct type, there is no way that any of Ronald
's fields will change without Fred
's knowledge and consent. Since nobody but Fred
can manipulate those fields, and since Fred
will know what it requires of the struct, it's simplest to simply have Fred
be the one responsible for maintaining any desired invariants.