So, this is actually this question is my current keystone.
I’m working on refactoring of my personal project, trying increase performance, optimize memory usage, make code easy and clear. I have a different application layers (actually, DAL, BLL, ServiceAgents which is WCF services). I’m using Entities/Models/DTOs to pass data between those layers, which is stateless (don’t have any logic at all). Currently they’re objects like this:
public class Person
{
public ComplexId Id { get; set; }
public string Name { get; set; }
// ...
}
I used to use such approach, it’s like a “best practice”, is it? Is this best way to store transferred data? What if I change it for struct like this:
public struct Person
{
public ComplexIdentifier ComplexId;
public string Name;
}
public struct ComplexIdentifier
{
public int LocalId;
public int GlobalId;
}
Is this would be better way from performance/memory usage perspective? Or maybe there is some kind of traps acting that way?
For standard DTO entities, you will want to stick with the class.
A
structhas a much more limited range of potential use cases than classes. There are also efficiency issues whenstructtypes 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 havingstructtypes exposed through properties, or accidentally box it when referencing interfaces, or make them mutable…I’m not saying not to use
structwhen it is relevant, but I very rarely find myself needing to usestructtypes in our main desktop application – which is layered and features DTO types.The performance issue cannot be answered as simply as
structvs.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.