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

Question

[Никита]

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

Хранение копий

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

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

Так и не понял из-за чего будут проблемы, если в тестах использовать локальную файловую систему; и не понимаю, как реализовать репозиторий, который будет работать с памятью. Понял только, что нужно использовать библиотеку MemoryMappedFile.

Answer 1

[Griboks]

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

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

резервные копии будут создаваться локально на файловой системе

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

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

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

Создайте класс для хранения данных, но не сохраняйте эти данные в файлы. В отчёте напишите, что поля класса - это и есть те самые виртуальные файлы.

Comments

[Никита]

Видимо, Ваш вариант самый подходящий. Вчера ответил преподаватель и сказал, что можно просто хранить имя файла и его путь. Я понял это так: в тестах нас не интересует содержимое файлов, нам нужно проверить корректность создания точек, копий - сам механизм создания резервных копий.

[Griboks]

Никита, я рад, что смог вам помочь.
В любом случае, пожалуйста, отметьте решением наиболее близкий ответ (не обязательно мой) для потомков или напишите свой.

[Никита]

Griboks, Да, конечно. Спасибо большое за помощь)

Answer 2

[freeExec]

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

Т.е. вы вместо FileRepository делаете MemoryRepositiory

Comments

[Никита]

1) Вы правы
2) Из-за чего тесты могут падать?
Проблема в том, что не понимаю, как все это связать. Есть алгоритмы, по которым создаются копии

Алгоритмы

Под созданием резервной копии файла подразумевается создание копии файла в другом месте. Система должна поддерживать расширяемость в алгоритмах создания резервных копий. Требуется реализовать два алгоритма:

1. Алгоритм раздельного хранения (Split storages) — для каждого объекта, который добавлен в джобу, создается копия - zip файл, в котором лежит объект.
2. Алгоритм общего хранения (Single storage) — все указанные в бекапе объекты сохраняются в один архив.

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

[freeExec]

Никита, и что тут не понятно?
1) В джобе 100 файлов - у вас 100 архивов
2) В джобе 100 файлов - у вас 1 архив

[Никита]

freeExec, Это я понимаю.
Вот, к примеру, у меня есть класс Zip, в котором есть методы. Эти методы работают напрямую с потоками, разве так должно быть?

public static class Zip
    {
        public static void Compress(string sourceFile, string compressedFile)
        {
            // поток для чтения исходного файла
            using (var sourceStream = new FileStream(sourceFile, FileMode.OpenOrCreate))
            {
                // поток для записи сжатого файла
                using (FileStream targetStream = File.Create(compressedFile))
                {
                    // поток архивации
                    using (var compressionStream = new GZipStream(targetStream, CompressionMode.Compress))
                    {
                        sourceStream.CopyTo(compressionStream); // копируем байты из одного потока в другой
                    }
                }
            }
        }

        public static void Decompress(string compressedFile, string targetFile)
        {
            // поток для чтения из сжатого файла
            using (var sourceStream = new FileStream(compressedFile, FileMode.OpenOrCreate))
            {
                // поток для записи восстановленного файла
                using (FileStream targetStream = File.Create(targetFile))
                {
                    // поток разархивации
                    using (var decompressionStream = new GZipStream(sourceStream, CompressionMode.Decompress))
                    {
                        decompressionStream.CopyTo(targetStream);
                        Console.WriteLine("Восстановлен файл: {0}", targetFile);
                    }
                }
            }
        }

        public static void CreateFromDirectory(string sourceDirectoryName, string destinationFileName)
        {
            ZipFile.CreateFromDirectory(sourceDirectoryName, destinationFileName);
        }

Эти методы использую в алгоритмах

[freeExec]

Никита, Для реализации на файловой системе, почему бы и нет.

[Никита]

freeExec, "Другие сущности (например, джоба) не должны напрямую работать с файловой системой, вызывать методы создания файла или директории." Разве я не нарушаю таким образом условие задачи?

[alexanderzanin]

Чтобы понять, в чем может быть проблема с тестами, это надо подумать о разработке продукта в команде. Допустим ваш функционал - это часть общего приложения, которое пилит команда из нескольких человек. К вашему функционалу вы дописали тесты, но писали вы их на своей машине под реализацию - хранение файлов не в памяти. При запуске у вас все работает. Закидываем все на деплой, и во время деплоя начинается запуск тестов, которые уже не выполняются - так как тесты запускаются в другой среде, в другом контейнере докера, у другого разработчика (если он выкачал вашу ветку). А реализация по SOLID в этом случае требует интерфейсов, чтобы потом замокать интефейс репозитория и подменить своей реализацией, которая как раз и хранит файлы в памяти.

[Никита]

Спасибо!

Answer 3

[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 и т.п.) так же храни в базе данных, может не так удобно как кажется с первого взгляда, но будет легче восстанавливать.

Comments

[Никита]

Спасибо за ответ. Лабораторная по ООП, и здесь больше акцент на проектировании и паттернах, чем на самом резервном копировании(наверное, нужно было прикрепить полное условие). Непонятно, как через репозиторий работать с источником данных.
p.s. могу добавить полное условие задачи, если хотите посмотреть)

[rPman]

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

[Никита]

rPman, по поводу репозитория
Что такое репозиторий и какие проблемы он решает?

В описании лабораторной, репозиторий - это абстракция над тем, куда и как будет записана копия файла. В самом простом случае, мы рассматривает файловую систему как репозиторий. Другие сущности (например, джоба) не должны напрямую работать с файловой системой, вызывать методы создания файла или директории. Вся эта логика выполняется за интерфейсом. Это позволит соответствовать DIP и OCP, легко добавить другие реализации, которые, например, будут сохранять копии сразу на гугл диск.

[alexanderzanin]

Никита, думаю суть вашей лабораторной довольно простая - понять, для чего вам интерфейс в DI. Допустим у вас есть один сервис, который работает с этим репозиторием, который сохраняет все на диск. Но допустим вам надо изменить репозиторий, чтобы он сохранял теперь в любое другое место. Если бы ваш репозиторий передавался в сервис через интерфейс, то тогда в сервис можно передать любой репозиторий, который реализует данный интерфейс. По сути, вы можете передать любой класс репозитория в сервис, если он реализует интерфейс - и приложение должно остаться работоспособным. В SOLID это объяснение есть.

[Никита]

alexanderzanin, Для чего нужен репозиторий я понял. Проблема была в том, что не понимал, как этот самый репозиторий сделать. В каком-то комментарии скидывал класс Zip. Сейчас посидел, подумал и понял, что создание zip файлов нужно перенести в репозиторий, иначе смысл репозитория теряется. Надеюсь, рассуждаю в правильном направлении)