DTO classes vs. struct
Is this would be better way from performance/memory usage perspective?
No. Structures are value types, so they're copied by value. This means that instead of copying just a reference, you will always copy the full object. If anything, it will probably be slightly slower and use more memory (since the object will duplicated).
Another reason why you should't do this: mutable structs should always be avoided, as they can cause unexpected behavior if you're not careful.
The two best choices for a data transfer object should generally be either a deeply-immutable class object, or a struct with exposed fields of types suitable for use as data transfer objects. Other types of structs may sometimes be usable as well, but exposed-field structs are by far the simplest, and that simplicity is a great virtue.
The notion that mutable structs are evil dates back to some early C# compilers which in which
SomeReadonlyStruct.SomeProperty = 5;
would be silently transformed by the compiler into:
var temp = SomeReadonlyStruct; temp.SomeProperty = 5;
Hiding struct fields behind readonly properties was an attempt to ensure the former statement would refuse to compile instead of yielding broken code. Since newer compilers will refuse to mutate writable fields of readonly structs, there's no longer any need to wrap fields in read-only properties.
Structs with exposed fields have a huge advantage compared with other types of data transfer objects: every struct which has exposed fields of types suitable for data-transfer and no other members else except perhaps a constructor behaves the same way, with no surprises. Someone who has never used structs might be a little surprised by the fact that they don't act like classes, but someone who understands how any such struct works will understand how they all work.
Consider the following code:
customerPhone = someDataSource.GetPhoneNumber(customerID); customerPhone.Extention = "5309"
Some people dislike the fact that if customerPhone is an exposed-field struct, setting the Extension property won't affect the information in someDataSource. While it's certainly true that writing a struct field won't update anything else, that's a much better situation than would exist if customerPhone were a mutable class type. Anyone who understands that customerPhone is an exposed-field struct type will know that changes to its members won't affect anything else. By contrast, if customerPhone is a mutable class type, code like the above might update someDataSource by changing the phone number associated with that customerID. Or it might not. Or, if one phone number was associated with two customerID values, the above code might change both of them. The amount of code one may have to study to determine exactly what effects and side effects the above code might have would be quite large. Worse, it may be difficult to be sure that one hasn't missed anything.
There are definitely some places where passing around class object references can be more efficient than passing around structs. There are also a few cases where mutable class objects can be useful data holders within a class. Some generic wrappers, however, can faclitate wrapping a struct in a mutable or immutable class, and exchanging the information between those types of classes.
interface IReadableHolder<T> { T Value {get;} }
class MutableHolder<T> : IReadableHolder<T>
{
public T Value;
IReadableHolder.Value {get {return Value;} }
public MutableHolder(T newValue) { Value = newValue; }
public MutableHolder(IReadableHolder<T> it) { Value = it.Value; }
}
class ImmutableHolder<T> : IReadableHolder<T>
{
T _Value;
public Value {get {return _Value;} }
public ImmutableHolder(T newValue) { _Value = newValue; }
}
Such a construct would be much more awkward without mutable structs.
For standard DTO entities, you will want to stick with the class.
A struct has a much more limited range of potential use cases than classes. There are also efficiency issues when struct types get too large (don't forget, they are value types and are copied when passed around), as outlined in the MSDN guidelines about value types. Not to mention plenty of gotchas when you start having struct types exposed through properties, or accidentally box it when referencing interfaces, or make them mutable...
I'm not saying not to use struct when it is relevant, but I very rarely find myself needing to use struct types in our main desktop application - which is layered and features DTO types.
The performance issue cannot be answered as simply as
struct vs. class. You will need to employ a profiling tool such as dotTrace or ANTS in order to find the hotspots and go from there. Performance issues are not trivial and good tooling is usually the start of the answer.
A struct may be more dangerous is that value types are handled much more differently by the CLR and if written poorly (e.g. a mutable struct) can create terrible headaches. Also, if your type contains many fields and then is passed from method to method you will be copying every field's value on each method call thus using more memory than if you had used a class in the first place.
The use of DTO (data transfer objects) which would encourage the separation of state and behavior. This can be a good design if done properly (and in most cases you would implement this pattern using classes, not structs).
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.