I’m stuck in an “advanced” ASP.NET class right now and my instructor just put forth an opinion that I’m not sure about. (I say “advanced” because he’s still using HTML tables for page layout and we just talked about the incredibly advanced topic of Master Pages. I need eye bleach!)
He states that instead of, say, creating a Person class that contains all of the data and methods applicable, you should create both a Person struct and and Person class. The struct contains what would normally be the properties for the Person class, and the class contains only methods. Since the Person struct sits on the stack, the data associated with your person goes away as soon as your method or whatever pops off of the stack instead of being garbage collected on the heap as with an object.
This is supposed to save memory and make the garbage collection process faster.
The question is: How big of an effect could this produce and is it really worth it?
There are several issues with the reasoning presented for pattern you describe.
First, structs are not always allocated on the stack. They are only stack-allocated when the are parameters to or local instances within a method. A struct that is defined as a member of a class is actually heap allocated. So the argument that a struct is more efficient because of the reduced effort for garbage collection is only true in certain narrow contexts.
Second, any non-ValueType members of a struct are also allocated on the heap (such as strings). So even if the struct can simply be popped off the stack, any heap objects it reference must still be garbage collected.
Third, structs rarely save memory since when passed around as method arguments they have value-semantics. This basically means that a copy of the struct is created and passed, and not a reference to the existing struct – this can’t be less expensive on memory. When you see other responses that say that mutable structs can be problem – it is for the reason (along with a few others) that since structs are passed by value, changes to the original struct aren’t available to locations that made a copy of the struct. This can lead you to violate assumptions or expectations within a program where you may have actually desired reference semantics for the struct.
Personally, I find the pattern of creating DTO objects (whether classes or structs) to nest within your business tier objects to be one that doesn’t seem to have much benefit. Unless you have a persistence or presentation layer that specifically leverages this pattern to pass information across tiers, I don’t see much value.
Furthermore, the specific case of using a struct as the DTO object seems flawed, because it introduces unnecessary redundancy. Since structs cannot inherit other structs, you can’t express is-a relationships. What do you do when you have Customer which inherits from Person. Do you repeat all of the Person properties in the Customer struct? Do you nest a Person struct inside a Customer struct? Neither approach is ideal. If you at least used classes, you could have Customer extend Person.