在.NET业务层中构造Vs类

Question

我现在陷入了一个"高级"ASP.NET课程,我的导师只是提出了一个我不确定的观点.(我说"高级",因为他仍然使用HTML表格进行页面布局,我们刚刚讨论了Master Pages非常高级的主题.我需要眼睛漂白!)

他声明,创建一个包含所有适用的数据和方法的Person类,而不是创建Person类和Person类.该结构包含通常为Person类的属性,并且该类仅包含方法.由于Person结构位于堆栈上,因此只要您的方法或任何弹出堆栈而不是像堆栈一样在堆上进行垃圾收集,与您的人员关联的数据就会消失.

这应该可以节省内存并使垃圾收集过程更快.

问题是:这会产生多大的影响并且真的值得吗？

Answer 1

说实话,我不相信你会从中看到很多性能上的好处.结构难以写好,写得不好的结构比对垃圾收集器征税要危险得多.

听起来你的教授主张使用数据传输对象,这会鼓励状态和行为的分离.如果正确完成,这可能是一个很好的设计(在大多数情况下,您将使用类而不是结构来实现此模式).

我说使用结构可能更危险的原因是CLR处理的值类型更加不同,如果写得不好(例如可变结构)会产生可怕的麻烦.此外,如果您的类型包含许多字段,然后从方法传递到方法,您将在每个方法调用上复制每个字段的值,因此使用的内存比您在第一个地方使用类时使用的内存更多.

Answer 2

针对您描述的模式提出的推理存在几个问题.

首先,结构并不总是在堆栈上分配.它们仅在方法中的参数或本地实例时进行堆栈分配.定义为类成员的结构实际上是堆分配的.因此,由于减少垃圾收集的努力,结构更有效的论点仅在某些狭窄的上下文中才是正确的.

其次,结构的任何非ValueType成员也在堆上分配(例如字符串).因此,即使结构可以简单地从堆栈中弹出,它引用的任何堆对象仍然必须进行垃圾回收.

第三,结构很少会节省内存,因为当它作为方法参数传递时,它们具有值语义.这基本上意味着创建并传递了结构的副本,而不是对现有结构的引用 - 这在内存上的成本不会太低.当你看到其他响应表明可变结构可能有问题时 - 原因(以及其他一些结果)由于结构是按值传递的,因此对原始结构的更改不适用于制作副本的位置结构.这可能会导致您违反程序中的假设或期望,在该程序中您可能实际需要结构的引用语义.

就个人而言,我发现在业务层对象中嵌套创建DTO对象(无论是类还是结构)的模式似乎没有什么好处.除非您有专门利用此模式的持久性或表示层来跨层传递信息,否则我看不到太多价值.

此外,使用结构作为DTO对象的特定情况似乎存在缺陷,因为它引入了不必要的冗余.由于结构不能继承其他结构,因此无法表达is-a关系.当您拥有继承自Person的Customer时,您会怎么做.您是否重复了Customer结构中的所有Person属性？您是否在Customer结构中嵌入Person结构？这两种方法都不理想.如果您至少使用过类,则可以让客户扩展Person.