@Nikitos2002

Как реализовать хранение файлов в памяти, используя репозиторий?

Есть лабораторная работа по C#, в которой требуется реализовать механизм для создания резервных копий. Сложности возникли с хранением копий. Вот что написано:
Хранение копий

В лабораторной работе подразуемвается, что резервные копии будут создаваться локально на файловой системе. Но логика выполнения должна абстрагироваться от этого, должна быть введена абстракция - репозиторий (см. принцип DIP из SOLID). И, например, в тестах стоит реализовать хранение в памяти, иначе тесты будут создавать много мусора, будут требовать дополнительной конфигурации, а также могут начать внезапно падать. Ожидаемая структура:

- Корневая директория
- Директории джоб, которые лежат в корневой директории
- Файлы резервных копий, которые лежат в директории джобы

Так и не понял из-за чего будут проблемы, если в тестах использовать локальную файловую систему; и не понимаю, как реализовать репозиторий, который будет работать с памятью. Понял только, что нужно использовать библиотеку MemoryMappedFile.
  • Вопрос задан
  • 137 просмотров
Решения вопроса 1
Griboks
@Griboks Куратор тега C#
Так и не понял из-за чего будут проблемы, если в тестах использовать локальную файловую систему;

Из-за того, что вы тестируете логику сериализации, а не логику сохранения в файл. Т.е. у вас предмет, среда и начальные условия совершенно другие.
резервные копии будут создаваться локально на файловой системе

в тестах стоит реализовать хранение в памяти

Прикольно... программа работает с файлами, а тестировать предлагают оперативную память. Очень полезное занятие, да?
не понимаю, как реализовать репозиторий, который будет работать с памятью.

Создайте класс для хранения данных, но не сохраняйте эти данные в файлы. В отчёте напишите, что поля класса - это и есть те самые виртуальные файлы.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
freeExec
@freeExec
Участник OpenStreetMap
Смею предположить, что имеется ввиду следующее:
1) Настоящая реализация должна использовать файловую систему для хранения файлов;
2) Ваша (чтобы не мусорить файлами на диске) хранит все эти байты в памяти.

Т.е. вы вместо FileRepository делаете MemoryRepositiory
Ответ написан
@rPman
DIP из SOLID
не уверен, на сколько глубоко ты готов залезать в проблему, так как в зависимости от этого будет и подход к разработке. Выбор - поддержка или нет практически любого из этих пунктов будут менять структуру и алгоритм чуть ли не полностью.

1. имена файлов и пути, а кодировки?
в разных ос разные правила, разные символы разделители, значимость больших/маленьких букв в именах
2. symbolic и hardlink свихнуться можно
это огромная головная боль для любых кто занимается копированием данных, поведение разнится к примеру, попадает ли путь в пределах каталогов, входящих в копию или нет
3. фичи типа sparce files или reflink (этакий hardlink но не для файла а на его сектора)
существуют задачи, в которых не сохранение и учет этих вещей могут невероятно усложнить восстановление данных (например если данные хранятся в дырявых файлах, логически петабайтового размера, в реальности же занимающие на порядки меньше, восстановить да и скопировать без учета этого будет практически нереально)
4. extended attributes
этим мало кто пользуется (но если пользуются то на столько глубоко, что не сделать резервную копию будет фатально), но помнить об этом надо, особенно когда нужно абстрагироваться от их реализации в ОС
5. права доступа
очень мало кто заморачивается с резервированием этой информации, а она зачастую не менее важна чем сами данные, так как иначе, при восстановлении данных со сложной структурой прав и большим количеством пользователей может превратиться в ад, и даже нести опасность утечки важных данных
6. инкрементальное хранение бакапов
это конечно не обязательно, но системы хранения резервных копий без этой фичи неудобны либо слишком дороги
7. работа с сетевыми nas, инструменты выборочного восстановления, поиск данных
Хранить бакапы локально - это фатальная ошибка, значит доступ к хранилищу должен быть удаленный
А еще, вероятность что понадобится восстановить весь бакап на столько низкая, по сравнению с другими сценариями, и заставлять человека извлекать петабайтовые архивы ради мегабайтового файлика, который удалили по ошибки и решили восстановить из бакапа...

p.s. не придумывай сам, спроси своего руководителя, на сколько глубока кроличья нора, так как к примеру все правильно сделать может тянуть на диплом или еще круче.

p.p.s. совет, не изобретай форматы хранения данных, храни все в файлах, пусть контейнером будет сама файловая система (не вздумай файлы хранить к примеру в БД), но вот за имена файлов придется чтобы отвечал кто то другой (вот тут БД), причем не рекомендуется полностью исключать имена файлов и каталогов из архива, достаточно составить список разрешенных символов (общих для большинства ос и основной кодировки) но это может наложить лимит на структуру данных (например в разных ос разный лимит глубины вложенности или длины символов в пути к файлу), тут же храни extended attributes (так же в виде файлов со своими именами)
Все остальное (настройки, структуру инкрементальных бакапов, права доступа, наличие дыр, symlink/hardlik, reflink и т.п.) так же храни в базе данных, может не так удобно как кажется с первого взгляда, но будет легче восстанавливать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы