Как лучше сделать структуру парсера? Как лучше организовать парсер сервисов с точки зрения ООП ? Есть несколько сайтов Т.е уже это несколько конкретных классов с методом parse parserA, parserB и все реализуют IParser где есть метод parse, который возвращает некий массив данных далее необходимо сохранить в бд эти данные (используется active record) в одинаковые таблицы (сайты разные но их данные нужно подогнать под один шаблон их) Как это лучше сделать? сделать отдельные классы в стиле mapperA , которые сохраняют данные класса А и тд ? или в IParse запихнуть метод save?
Для более гибкой и модульной структуры парсера можно использовать шаблон проектирования "Стратегия". В данном случае, можно создать интерфейс IParser, который содержит метод parse для парсинга данных, а также создать интерфейс ISaver с методом save для сохранения данных в БД.
Затем для каждого сайта создать отдельные классы-парсеры (например, ParserA, ParserB), которые реализуют интерфейс IParser и имеют свою уникальную реализацию метода parse для парсинга данных с конкретного сайта.
Для сохранения данных в БД можно создать отдельные классы-сейверы (например, SaverA, SaverB), которые реализуют интерфейс ISaver и имеют свою уникальную реализацию метода save для сохранения данных конкретного класса парсера в БД.
Таким образом, вы получите гибкую и расширяемую архитектуру парсера, где каждый компонент (парсер и сейвер) отвечает только за свою функциональность и легко заменяем при необходимости.
Для более гибкой и модульной структуры парсера можно использовать шаблон проектирования "Стратегия". В данном случае, можно создать интерфейс IParser, который содержит метод parse для парсинга данных, а также создать интерфейс ISaver с методом save для сохранения данных в БД.
Затем для каждого сайта создать отдельные классы-парсеры (например, ParserA, ParserB), которые реализуют интерфейс IParser и имеют свою уникальную реализацию метода parse для парсинга данных с конкретного сайта.
Для сохранения данных в БД можно создать отдельные классы-сейверы (например, SaverA, SaverB), которые реализуют интерфейс ISaver и имеют свою уникальную реализацию метода save для сохранения данных конкретного класса парсера в БД.
Таким образом, вы получите гибкую и расширяемую архитектуру парсера, где каждый компонент (парсер и сейвер) отвечает только за свою функциональность и легко заменяем при необходимости.