Структура парсера в модуле.

[Vladbara705]

Здравствуйте.
Делаю, можно сказать, парсер(не совсем).
Хочу реализовать его в отдельном модуле.
Есть 5 таблиц в БД.
Вид спорта, название чемпионата,событие,коэффициенты события,таблица связывающая событие и коэффициенты.

Правильно ли будет следующее :
Сделаю отдельную модель, в которой я буду держать логику и парсить информацию.
Затем информацию, которую спарсил буду отдавать в контроллер и оттуда записывать в БД через модели, которые связаны с таблицами?

Есть ли какие нибудь примеры?

[Loveorigami]

Не модель, а компонент. Там вся логика.
Станете поопытнее - сделаете через интерфейсы, сервисы, репозиотрии, фабрики...

[Vladbara705]

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

Где обычно находятся сервисы и как их создать ?(прошу указать директорию и т.д.)
Как создать и использовать репозиторий ?
Для чего там используются интерфейсы ?

Прошу разжевать более подробно и с примерами, по возможности.

[Loveorigami]

Не, не, не....) Там была оговорка. "Станете поопытнее...".
Опыт приходит, когда Вы делаете сами.
Вот когда Вы сделаете сами, и Вам будет казаться, что вроде - хорошо, мы вместе разберем тут и сервисы, и репозиторий, и интерфейсы...
Вечерком (днем работа...), с чашечкой кофе, неспеша ... Вот тогда Вы запомните все и надолго...

[skynin]

Хочу реализовать его в отдельном модуле.
Есть 5 таблиц в БД.
Вид спорта, название чемпионата,событие,коэффициенты события,таблица связывающая событие и коэффициенты.

Правильно ли будет следующее :
Сделаю отдельную модель, в которой я буду держать логику и парсить информацию.
Затем информацию, которую спарсил буду отдавать в контроллер и оттуда записывать в БД через модели, которые связаны с таблицами?

Есть ли какие нибудь примеры?

1.
Если бизнес-логика требует работы с несколькими таблицами, то ее лучше выносить в отдельный слой, объекты из контроллеров и ActiveRecord

В вашем случае можно ее вынести в класс модуля (тот который наследуете от \yii\base\Module и регистрируете в config\main). Если ее будет много, то этот класс конечно начнет захламлятся, и лучше будет и из него вынести.
Но пока - хотя бы в него выносите.

И, в контроллерах работа только с методами бизнес-логики, которые могут возвращать один или список ActiveRecord
В самих ActiveRecord делаете валидациию только низкооуровневую, на явную некорректность, а бизнес-валидация делается в классе модуля

2.
Создаете на каждое бизнес-действие отдельный класс, наследуется от базового yii\base\Model
и в нем совершаете все манипуляции - парсинг, и запись в таблицы, используя свои ActiveRecord для таблиц.
Контроллер работает только с этим классом, вызывая его load() и save()/run()/doIt() - какой добавите для самого действия.
в нем, по стандарту Yii2 опишите вызов валидации, и т.п.
Посмотрите как реализованы LoginForm, SignupForm, ResetPasswordForm, NewPasswordForm

То есть, для контроллера такой класс выглядит фактически как ActiveRecord

Главное
выносите сложные действия из контроллеров и ActiveRecord в отдельные классы, слои
а не раздувайте ими контроллеры или ActiveRecord