他声明,而不是创建一个包含所有适用的数据和方法的Person类,您应该创建Person结构和Person类.该结构包含通常为Person类的属性,该类仅包含方法.由于Person结构位于堆栈上,因此只要您的方法或任何弹出堆栈而不是像堆栈一样在堆上进行垃圾收集,与您的人员关联的数据就会消失.
这应该可以节省内存并使垃圾收集过程更快.
问题是：这会产生多大的影响并且真的值得吗？
解决方法
首先,结构并不总是在堆栈上分配.它们仅在方法中的参数或本地实例时进行堆栈分配.定义为类成员的结构实际上是堆分配的.因此,由于减少垃圾收集的努力,结构更有效的论点仅在某些狭窄的上下文中才是真实的.
其次,结构的任何非ValueType成员也在堆上分配(例如字符串).因此,即使结构可以简单地从堆栈弹出,它引用的任何堆对象仍然必须被垃圾收集.
第三,结构很少节省内存,因为当它作为方法参数传递时它们具有值语义.这基本上意味着创建并传递了结构的副本,而不是对现有结构的引用 – 这在内存上的成本也不低.当您看到其他响应表明可变结构可能会出现问题时 – 原因(以及其他一些结果)由于结构是按值传递的,因此对原始结构的更改不适用于制作副本的位置结构.这可能会导致您违反程序中的假设或期望,在该程序中您可能实际需要结构的引用语义.
就个人而言,我发现创建DTO对象(无论是类还是结构)的模式在业务层对象中嵌套是一个似乎没有多大好处的模式.除非您有专门利用此模式的持久性或表示层来跨层传递信息,否则我看不到太多价值.
此外,使用结构作为DTO对象的特定情况似乎存在缺陷,因为它引入了不必要的冗余.由于结构不能继承其他结构,因此无法表达is-a关系.当您拥有继承自Person的Customer时,您会怎么做.您是否重复Customer结构中的所有Person属性？您是否在Customer结构中嵌入Person结构？这两种方法都不理想.如果您至少使用过类,则可以让客户扩展Person.
