Хорошие причины для передачи путей как строк вместо использования DirectoryInfo/FileInfo
В моем новом коде я не использую строки для передачи путей к каталогам или имен файлов. Вместо этого я использую DirectoryInfo и FileInfo, поскольку они, похоже, инкапсулируют много информации.
Я видел много кода, который использует строки для передачи информации каталога, а затем "split" и "mid" и "instr" в длинных непонятных операторах, пока они не получат часть каталога, который они ищут.
Есть ли веская причина, чтобы передавать пути как строки?
Ответы
Ответ 1
В общем, я считаю, что лучше хранить информацию в FileInfo/DirectoryInfo. В этих классах есть много полезной функциональности, а также большая безопасность, так что гораздо проще проверить наличие файла, посмотреть его исходный файл и т.д.
Единственное место, где я мог бы (потенциально) передать путь как строку, а не использовать FileInfo и DirectoryInfo, будет ли путь проходить через AppDomains или между процессами и т.д.
FileInfo и DirectoryInfo работают отлично в границах AppDomain (поскольку они являются Serializable), но в этой ситуации у них есть еще много накладных расходов. Если что-то идет вперед и назад, это может повлиять.
В этом случае я бы придерживался FileInfo и DirectoryInfo, если не обнаружил, что во время моего профилирования была заметная проблема, и я пытался уменьшить количество сериализованных данных. Если бы я не столкнулся с проблемами производительности, я бы придерживался этих классов, поскольку они обеспечивают большую безопасность и функциональность.
Ответ 2
DirectoryInfo и FileInfo ужасно тяжелы для прохождения, если все, что вам нужно, это путь. Меня больше волнует "раскол и середина" и "instr". Изучите способы:
Path.GetFileName
Path.GetDirectoryName
Path.Combine
и т.д.
Это из класса System.IO.Path, btw.
Ответ 3
Как только путь находится в приложении (т.е. не в файле конфигурации простого текста), нет, нет веской причины.
Единственное время (я могу придумать), что это может быть полезно, - это взаимодействовать с кодом, который принимает только пути как строки.
Ответ 4
У меня возникли проблемы при передаче FileInfo в DMZ. Насколько я могу судить - исправьте меня, если я ошибаюсь - FileInfo выполняет проверку разрешений при десериализации, и это не будет работать из DMZ и приведет к "пути не найден". Создайте и передайте пользовательский объект с данными, которые вы используете.
Ответ 5
Я думаю, что вам нужен класс для инкапсуляции пути к файлу или каталогу, вместо того, чтобы использовать необработанные строки и манипулировать ими, используя статический класс System.IO.Path. Тем не менее, Я не считаю DirectoryInfo и FileInfo подходящими, потому что они, похоже, больше предназначены для выполнения манипуляций с файлами и каталогами вместо операций с путями. Если вы создаете пользовательский класс для манипуляций с пути, вы можете обеспечить более удобные для пользователя функции управления трафиком.
