处置& 最终确定属性集合？
我正在查看我刚刚继承的一些 vb.net 代码，无法理解为什么原始开发人员会这样做。
基本上，每个“域”类都是属性的集合。 每个都实现 IDisposable.Dispose，并重写 Finalize()。 没有基类，因此每个类都只是扩展对象。
Dispose 将每个私有变量设置为 Nothing，或者当属性是另一个域对象时调用 _private.Dispose。 有一个私有变量跟踪已处置状态，Dispose 中的最后一件事是 GC.suppressFinalize(Me)
Finalize 只是调用 Me.Dispose 和 MyBase.Finalize。
这有什么好处吗？ 有什么坏处吗？ 没有非托管资源，没有数据库连接，似乎没有什么需要的。
I'm looking at some vb.net code I just inherited, and cannot fathom why the original developer would do this.
Basically, each "Domain" class is a collection of properties. And each one implements IDisposable.Dispose, and overrides Finalize(). There is no base class, so each just extents Object.
Dispose sets each private var to Nothing, or calls _private.Dispose when the property is another domain object. There's a private var that tracks the disposed state, and the final thing in Dispose is GC.suppressFinalize(Me)
Finalize just calls Me.Dispose and MyBase.Finalize.
Is there any benefit to this? Any harm? There are no un-managed resources, no db connections, nothing that would seem to need this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我觉得这是一个 VB6 模式。
我敢打赌，这个人是直接来自 VB6，也许是在 .NET 的早期，当时这些模式还没有被广泛理解。
还有一种情况是，在调用 Dispose 时设置对任何内容都没有用的内部引用：当成员标记为 Withevents 时。
如果没有这个，您可能会面临一个未收集的对象处理事件的风险，而实际上它不应该再这样做了。
That strikes me as being a VB6 pattern.
I would bet the guy was coming straight from VB6, maybe in the earlier days of .NET when these patterns were not widely understood.
There also is one case were setting an nternal reference to nothing is useful in a call to Dispose: when the member is marked as Withevents.
Without that, you risk having an uncollected object handling events when it really should not be doing that anymore.
在我看来，这是根本不需要的，特别是在没有非托管资源和数据连接的情况下。
如果您碰巧能够清理并发布代码，我们也许能够获得更多的见解，但实际上我认为没有必要。
It would seem to me that this is something that is NOT needed at all, especially without un-managed resources and data connections.
If you happen to be able to sanitize and post the code we might be able to get a bit more insight, but realistically I can't see a need for it.
根据对象的大小以及它们创建/销毁的频率，可以确保 GC 尽早发生。
可能这种模式已在其他项目中使用，并且在不了解最初使用它的原因的情况下继续使用。 猴子园丁
Depending on the size of the objects, and how often they are created/destroyed, it could be to ensure GC can happen as early as possible.
It may be, that this pattern was used in other projects and it continues on without understanding why it was used in the first place. Monkey Gardeners
我能看到这一点的唯一原因（这充其量是可疑的）是，如果这些东西是在“食物链”的更高层中创建和处置的，并且其中一些域类有可能具有在某些时候是有限的或不受管理的资源。
即使这样也很粗略……听起来好像有人来自非托管背景，正在寻找相当于管理内存的 .NET，并遇到了
IDisposable接口。The only reason that I could see for this -- and this is dubious at best -- is if these things are being created and disposed of higher in the "food chain" and there is a potential for some of these domain classes to have either a limited or unmanaged resource at some point.
Even that is sketchy...it sounds like someone came from an unmanaged background and was looking for the .NET equivalent to managing your memory and came across the
IDisposableinterface.