为何要通过自定义类调用File.Delete()？VB.Net Web服务场景疑问

云原生阿岚

2026-5-28

关于sFTP.Files包装类调用File.Delete()意义的疑问

在VB.Net Web服务的多个类中，存在大量如下代码：

Dim sfile As New sFTP.Files
sfile.DeleteFile(strPath_to_File)

此外，DeleteFile函数的内部实现为：

namespace sFTP {
    public class Files {
        public void DeleteFile(string path) {
            try {
                File.Delete(path);
            } catch (Exception ex) {
                throw ex;
            }
        }
    }
}

请问使用包装类调用File.Delete()的意义是什么？我曾听闻共享类会影响IIS性能，但File本身就是共享类，这种做法有何优势？

我的分析与解答

从当前这个包装类的实现来看，它确实没做任何实质性的额外工作——捕获异常又直接抛出，和直接调用File.Delete完全等价。但这种设计之所以存在，大概率是出于未来扩展性或者架构规范的考虑，我给你拆解几个可能的原因：

统一扩展入口：现在只是简单转发，但如果未来需求变化了呢？比如要添加文件删除日志、校验操作权限、处理跨平台路径差异，甚至切换到真正的SFTP协议（而非本地文件操作），这个包装类就能直接在内部修改实现，所有调用它的业务代码都不需要改动。要是之前直接用File.Delete，那改起来就得逐个文件替换，成本高得多。
遵循分层架构规范：很多团队会要求把基础操作（比如文件IO、数据库访问）封装到专门的基础设施层/工具类中，业务层只和这些封装后的类交互。这样能让代码结构更清晰，符合单一职责原则——业务类不用关心底层文件操作的细节，只需要调用封装好的方法即可。
历史遗留或设计残留：也许这个Files类最初设计时有更多功能，后来部分功能被砍掉但代码没清理；或者之前团队对File静态类有不必要的顾虑（比如你提到的IIS性能问题），但实际上File.Delete是非常轻量的静态方法，静态类在.NET里是AppDomain级别的单例，初始化一次后就常驻内存，性能反而比每次new实例的类更好——所谓“共享类影响性能”的说法在这里并不成立。
异常处理的潜在扩展：现在的代码只是捕获后直接抛出，但未来可以在这里统一处理异常，比如转换成自定义业务异常、添加错误上下文（比如当前要删除的文件路径），这样上层业务代码能更方便地定位问题，而不是拿到一个无上下文的系统异常。

至于每次new sFTP.Files实例的做法，反而比直接用File静态方法多了一点点对象创建的开销，但这点开销在Web服务场景下几乎可以忽略不计。

总结来说：这个包装类现在看起来有点多余，但它是为未来的需求变化预留的扩展口子，也是架构规范的一种体现——如果后续团队有文件操作的扩展需求，这个类就能发挥关键作用。

内容的提问来源于stack exchange，提问作者Óscar Alberto Fernández Muñoz