Шаблон проектирования для анализа данных двоичного файла и хранения в базе данных

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

Я думаю, что подобный шаблон можно использовать для взятия XML или файла с разделителями табуляции и его анализа на их репрезентативные объекты.

Общая структура данных будет включать:

(Header) (DataElement1) (DataElement1SubData1) (DataElement1SubData2)(DataElement2) (DataElement2SubData1) (DataElement2SubData2) (EOF)

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

Повышение качества Laravel с помощью принципов SOLID: Лучшие практики и примеры
Повышение качества Laravel с помощью принципов SOLID: Лучшие практики и примеры
Когда мы говорим о том, как сделать следующий шаг в качестве разработчика, мы должны понимать, что качество кода всегда является основным фокусом на...
Принципы SOLID - лучшие практики
Принципы SOLID - лучшие практики
SOLID - это аббревиатура, обозначающая пять ключевых принципов проектирования: принцип единой ответственности, принцип "открыто-закрыто", принцип...
6
0
7 602
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

Возможно, вам стоит взглянуть на паттерн Стратегия. Стратегия заключается в алгоритме разбора файлов.

Тогда вам нужна отдельная стратегия для вставки базы данных.

Ответ принят как подходящий
  1. Просто напишите свой файловый парсер, используя любые техники, которые придут в голову.
  2. Напишите множество модульных тестов, чтобы убедиться, что все ваши крайние случаи покрыты

Как только вы это сделаете, у вас действительно будет разумное представление о проблеме / решении.

Прямо сейчас у вас в голове крутятся теории, большинство из которых оказывается ошибочным.

Шаг 3. Беспощадный рефакторинг. Ваша цель должна состоять в том, чтобы удалить примерно половину вашего кода.

Вы обнаружите, что ваш код в конце либо будет напоминать существующий шаблон проектирования, либо вы создадите новый. После этого вы сможете ответить на этот вопрос :-)

Я полностью согласен с Орионом Эдвардсом, и обычно я так подхожу к проблеме; но в последнее время я начал замечать некоторые закономерности (!) до безумия.

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

Для потоковой передачи данных весь синтаксический анализатор будет выглядеть примерно как адаптер, адаптируясь от объекта потока к потоку объектов (который обычно представляет собой просто очередь).

В вашем примере, вероятно, будет один построитель для полной структуры данных (от заголовка до EOF), который внутренне использует построители для внутренних элементов данных (подаваемых интерпретатором). При обнаружении EOF объект будет испущен.

Однако создание объектов с помощью оператора switch в какой-либо фабричной функции, вероятно, является самым простым способом решения многих более мелких задач. Кроме того, мне нравится сохранять неизменность моих объектов данных, потому что никогда не угадаешь, когда кто-то затолкает тебе в глотку параллелизм :)

Используйте Лекс и YACC. Если следующие десять лет вы не посвятите исключительно этой теме, они каждый раз будут создавать лучший и более быстрый код.

Другие вопросы по теме