MVVM / IoC я должен обернуть каждую операцию ввода-вывода?

Question

В коде C #, соответствующем стандартам IoC, следует ли заключать каждую отдельную операцию ввода-вывода в класс, обрабатывающий операции ввода-вывода? Например, я использую File.Exists и Directory.Create повсеместно - должен ли я иметь класс, представляющий эти 2 функции и каждую отдельную файловую операцию, которую использует все приложение, для создания уровня абстракции?

Как насчет Path.Combine или Path.DirectorySeparatorChar, я могу использовать это напрямую или я должен также создавать обертки вокруг них?

Возвращение информации о файле становится немного сложнее, у меня может быть функция для возврата размера файла, но если мне нужно получить доступ к нескольким свойствам, я возвращаю объект FileInfo - разве я не должен просто инициализировать FileInfo в коде вместо того, чтобы обернуть это?

Answer 1

Нельзя и не следует универсально утверждать, что нужно и что нельзя делать в контексте внедрения зависимостей (DI). Это действительно зависит от типа проблемы, которую вы пытаетесь решить. Если единственной проблемой является тестируемость, то желательно скрыть все, что не является детерминированным или имеет побочные эффекты.

Обратите внимание, что это не включает Path.Combine или Path.DirectorySeparatorChar. Эти члены, IIRC, полностью детерминированы; они не обращаются к файловой системе, когда вы вызываете их.

Обычный подход к DI, однако, заключается в применении принципа обращения зависимостей (DIP). Согласно этому принципу, клиентский код решает и управляет формой полиморфных API, которые он использует. Как только клиентский код очистит требуемые интерфейсы, вы поймете, как реализовать эти интерфейсы.

Многие пытаются сопоставить тестируемость с файловой системой Windows, например, System.IO.Abstractions , но это полностью нарушает DIP. Вместо того, чтобы позволить клиентам определять форму интерфейсов, он позволяет реализации определять API. Это негерметичная абстракция , если это вообще абстракция.

Answer 2

Нашел ответ.

Отключение вызовов IO означает, что вы не можете выполнить юнит-тестирование класса, поскольку он будет изменять реальные файлы, а не работать в песочнице.

Это означает, что да, каждый вызов должен быть упакован. К счастью, System.IO.Abstraction обеспечивает такую ​​абстракцию, поэтому просто подключите ее к проекту и используйте ее.

Затем я могу создать IFileSystemExt для предоставления общих наборов операций ввода-вывода, таких как «убедиться, что папка пути существует» и «удалить файл, если он существует».