Данные в XML-файлах: Один большой файл или несколько маленьких?
Можно вынудить Visual Studio проигнорировать то, что это - код впереди, Вы работаете с путем движения в:
Инструменты | Опции
И открытие вкладки "Text Editor | File Extensions".
Создают новую запись для расширения "ashx", отображенный на редакторе "Microsoft Visual C#" (или "Microsoft Visual Basic", поскольку Ваше предпочтение берет Вас), и "Добавьте" его.
хорошо диалоговое окно, закройте и вновь откройте свой ashx файл и свои блоки кода willl коллапс к Вашему содержанию основ, но директива будет довольно ужасна.
у Вас есть та же проблема, если у Вас есть сценарий серверной стороны в .aspx файле (например, в проекте веб-сайта, и Вы "Не помещаете код в отдельный файл"), затем Вы не можете свернуть блоки класса там также.
5 ответов
Здесь уже много вдумчивых отзывов.
Либо 1 большой файл, либо много маленьких файлов должны работать нормально. Сферы, о которых стоит подумать, чаще всего связаны с администрированием и обслуживанием. Если сложно поддерживать элементы, потому что они находятся в группе разных файлов, то, возможно, ответом будет один большой файл.
Некоторые мысли:
Один большой файл означает, что одна ошибка (недопустимый xml) может привести к сбою все приложение, в то время как многие файлы будут влиять только на страницы, использующие этот элемент (ы). Снижается за счет отказа от редактирования данных в производственной среде.
Есть ли у каждого сервера своя собственная файловая структура элементов? Или элементы расположены в одной общедоступной папке с высокой доступностью? Чем больше копий данных у вас есть, тем больше вероятность того, что данные будут рассинхронизированы на определенном сервере, что может быть трудно отследить.
Независимо от того, выберете ли вы 1 файл или несколько файлов, вы, скорее всего, сможете решить / абстрагировать любые проблемы доступа к данным (блокировка, поиск и т. Д.) В коде. Чем больше кода вы должны написать для таких вещей, как блокировка, поиск, тем больше ошибок вам, вероятно, придется отлаживать.
Рассмотрите возможность кэширования элементов на определенный период времени, чтобы избежать доступа к диску, если производительность начинает становиться проблемой.
] Возможно, вам захочется проверить механизм ведения блогов dasBlog Скотта Хансельмана . Я считаю, что это, по сути, система управления контентом на основе xml / текстовых файлов, в которой используется подход, основанный на множестве файлов, и ее может быть полезно изучить.
Рассмотрите возможность кэширования элементов в течение определенного периода времени, чтобы избежать доступа к диску, если производительность начинает становиться проблемой.
Вы можете проверить Скотт Хансельман механизм ведения блогов dasBlog . Я считаю, что это, по сути, система управления контентом на основе xml / текстовых файлов, в которой использовался подход, основанный на множестве файлов, и ее было бы полезно изучить.
Рассмотрите возможность кэширования элементов в течение определенного периода времени, чтобы избежать доступа к диску, если производительность начинает становиться проблемой.
Вы можете проверить Скотт Хансельман механизм ведения блогов dasBlog . Я считаю, что это, по сути, система управления контентом на основе xml / текстовых файлов, в которой используется подход, основанный на множестве файлов, и ее может быть полезно изучить.
Я думаю, что ваш нынешний подход лучше из двух альтернатив. Если ваши пользователи используют интерфейс, созданный вами для редактирования файлов, они в любом случае не будут искать файлы в каталоге с большим количеством файлов.
Учитывая, что требуется для повреждения файла, преимущество многих файлов в том, что вы не получите один большой успех, но попадание только в один файл. Блокировка также лучше, поскольку для записи блокируется только один файл, а не полный «главный файл XML».
Будет ли ваш пользователь работать с файлами XML напрямую или это просто способ хранить данные?
Если последнее, то это техническая проблема, а доступ к диску и скорость анализа являются важными проблемами.
В первом случае наиболее важным вопросом является то, что имеет наибольший смысл для пользователя. Затем вы можете решить технические проблемы с кешированием и т. Д. Итак, предполагая, что пользователь работает напрямую с XML-файлами, вы должны спросить себя, помогает или мешает вашему пользователю иметь несколько файлов или один файл. Если каждый элемент описывает отдельный компонент, а отношения с другими элементами мало или отсутствуют, я бы поместил их в отдельные файлы. Если вы создадите один файл с множеством несвязанных элементов, пользователь потратит много времени на поиск нужного элемента. Если у вас несколько файлов, он может использовать имя файла, чтобы сразу выбрать нужный.
Если вы не просто идете по маршруту базы данных, который, как мне кажется, очевиден, я бы предложил несколько файлов. Основная причина заключается в том, что если вы используете только один файл и обновляете его, ваше приложение должно анализировать весь файл при повторном отображении страницы, что является плохим моментом (tm).
Я думаю, это зависит от того, сколько памяти у вашего сервера; насколько велики файлы XML; и какой парсер вы используете. Если на сервере много памяти, я думаю, что один XML-файл был бы предпочтительнее, поскольку его можно было бы кэшировать в памяти, а затем легко анализировать. Я думаю, что это перевесит накладные расходы ввода-вывода при открытии / чтении многих файлов.
Кроме того, в будущем он будет намного удобнее в обслуживании и гибкостью. Например, если вы хотите создать список всех элементов или, возможно, выполнить поиск по ним, тогда будет очень сложно использовать много отдельных файлов XML. Чтобы использовать аналогию с базой данных - если бы у вас были общие данные страницы в БД, вы бы создали отдельную таблицу для каждой страницы? Конечно, нет.