ADO.NET大量实现IDisposable是否设计过度？

当年.NET刚推出的时候，我跟很多同行一样，对它缺少确定性终结这件事抱怨不已——毕竟类的析构函数什么时候被调用完全没个准儿，对于需要及时释放非托管资源的场景来说，这简直是个大麻烦。

微软当时给出的折中方案就是using语句。平心而论，这方案算不上完美，但我始终认为，用using来保证非托管资源被及时清理，是写.NET代码时必须重视的操作。

不过我在编写ADO.NET代码的时候，发现了一个挺闹心的问题：几乎每个和数据库操作相关的类都实现了IDisposable接口。这直接导致代码看起来层层嵌套、臃肿不堪——比如你要执行一段数据库查询，得先把SqlConnection包在using里，里面再套SqlCommand的using，如果还要用SqlDataReader，那又是一层嵌套，整个代码块的缩进越来越深，可读性大打折扣。

当然，后来也摸索出一些优化方式：

• 从C# 8开始支持的using声明，可以直接在变量声明时加上using，不用再写嵌套的大括号，能大幅简化代码；
• 把资源的创建、释放逻辑封装成辅助方法，让业务代码只关注核心逻辑，不用被资源管理的样板代码干扰。

但说实话，刚接触ADO.NET的时候，满屏的using嵌套真的让人头大，谁也不想把时间浪费在写重复的样板代码上对吧？

内容的提问来源于stack exchange，提问作者Jonathan Wood