c# - MVVM/IoC 我应该包装每个 IO 操作吗？

在遵循 IoC 标准的 C# 代码中，是否应该将每个 IO 操作都包装在处理 IO 操作的类中？例如，我到处都在使用 File.Exists 和 Directory.Create ——我是否应该有一个类来公开这两个函数以及整个应用程序使用的每个文件操作，以创建一个抽象层？

Path.Combine 或 Path.DirectorySeparatorChar 怎么样，我可以直接使用它还是应该围绕它们创建包装器？

返回文件信息变得有点棘手，我可以有一个函数来返回文件大小，但是如果我需要访问几个属性，那么我返回 FileInfo 对象——我不应该只是在代码中初始化 FileInfo 而不是包装它？

标签： c#mvvminversion-of-control

在依赖注入 (DI) 的上下文中，不能也不应该普遍说明必须做什么和不应该做什么。这实际上取决于尝试解决的问题类型。如果唯一关心的是可测试性，那么隐藏任何不确定或具有副作用的东西可能是可取的。

但请注意，这不包括Path.Combineor Path.DirectorySeparatorChar。IIRC，这些成员是完全确定的；当您调用它们时，它们不会访问文件系统。

然而，DI 的一种常见方法是应用依赖倒置原则(DIP)。根据这个原则，客户端代码决定和控制它使用的多态 API 的形状。一旦客户端代码清除了它需要的接口，你就去弄清楚如何实现这些接口。

许多人尝试使用诸如System.IO.Abstractions之类的东西来解决针对 Windows 文件系统的可测试性，但这完全违反了 DIP。它不是让客户端定义接口的形状，而是让实现定义 API。这是一个泄漏的抽象，如果它是一个抽象的话。