Какая должна быть архитектура приложения, без ActiveRecord в Yii2? Вот мы на скорую руку создали проект на AR (ActeveRecord) запросы через него, запись и обновление. Для старта нового проекта я считаю это вполне норм, при том, что проект может не взлететь.
Но вот проект живет, модели AR распухают логикой. Растет база, вместе с ней объемы обрабатываемой информации. И нужно уже задумываться, как логику вынести из AR (behaviors, AfterSave, BeforeSave) в первую очередь, чтоб её можно было применять при batchInsert и batchUpdate.
Небольшое отступление, по поводу логики, примеры:Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.Обновить/удалить кэш или обновить индекс в elasticSearchОтправить на модерацию данныеИ все тому подобное
---
Есть мысли, что нужно это все вынести в обработчики и события, например какой то класс занимается обработкой измененных данных (сравнивает старые данные с новыми) и создает события, причем выполнения действий по событиям должны обрабатываться где то в очереди, в отдельно, чтоб текущую задачу по batchInsert и batchUpdate в несколько тысяч записей это не тормозило.
Но как это должно выглядеть архитектурно, какие нюансы и подводные камни?
Думаю я не первый кто этим вопросом задался, и уже есть какие то архитектурные решения.
Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей. Но на практике, без опыта - это не просто
Какая должна быть архитектура приложения, без ActiveRecord в Yii2? Вот мы на скорую руку создали проект на AR (ActeveRecord) запросы через него, запись и обновление. Для старта нового проекта я считаю это вполне норм, при том, что проект может не взлететь.
Но вот проект живет, модели AR распухают логикой. Растет база, вместе с ней объемы обрабатываемой информации. И нужно уже задумываться, как логику вынести из AR (behaviors, AfterSave, BeforeSave) в первую очередь, чтоб её можно было применять при batchInsert и batchUpdate.
Небольшое отступление, по поводу логики, примеры:Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.Обновить/удалить кэш или обновить индекс в elasticSearchОтправить на модерацию данныеИ все тому подобное
---
Есть мысли, что нужно это все вынести в обработчики и события, например какой то класс занимается обработкой измененных данных (сравнивает старые данные с новыми) и создает события, причем выполнения действий по событиям должны обрабатываться где то в очереди, в отдельно, чтоб текущую задачу по batchInsert и batchUpdate в несколько тысяч записей это не тормозило.
Но как это должно выглядеть архитектурно, какие нюансы и подводные камни?
Думаю я не первый кто этим вопросом задался, и уже есть какие то архитектурные решения.
Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей. Но на практике, без опыта - это не просто
Но вот проект живет, модели AR распухают логикой. Растет база, вместе с ней объемы обрабатываемой информации. И нужно уже задумываться, как логику вынести из AR (behaviors, AfterSave, BeforeSave) в первую очередь, чтоб её можно было применять при batchInsert и batchUpdate.
Небольшое отступление, по поводу логики, примеры:Изменился статус заказа, нужно отправить уведомления на почту, телеграм и тп. Записать в историю изменения суммы заказа, статуса.Обновить/удалить кэш или обновить индекс в elasticSearchОтправить на модерацию данныеИ все тому подобное
---
Есть мысли, что нужно это все вынести в обработчики и события, например какой то класс занимается обработкой измененных данных (сравнивает старые данные с новыми) и создает события, причем выполнения действий по событиям должны обрабатываться где то в очереди, в отдельно, чтоб текущую задачу по batchInsert и batchUpdate в несколько тысяч записей это не тормозило.
Но как это должно выглядеть архитектурно, какие нюансы и подводные камни?
Думаю я не первый кто этим вопросом задался, и уже есть какие то архитектурные решения.
Хотелось бы увидеть какие то примеры, потому что на словах это все просто, создай сервис, добавь репозиторий, там же наблюдателей. Но на практике, без опыта - это не просто
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
В случае, когда нужно вынести логику из ActiveRecord моделей в Yii2, можно использовать шаблон проектирования сервисов.
Создание сервисов:
Создайте классы сервисов, которые будут содержать всю бизнес-логику отдельных функциональных областей вашего приложения (например, OrderService, NotificationService и т.д.).В этих классах опишите методы для выполнения нужных действий (например, changeOrderStatus, sendNotifications и т.д.).В методах сервисов вызывайте необходимые операции с данными (чтение, запись, обновление) через репозитории.Создание репозиториев:
Создайте отдельные классы репозиториев для работы с данными (например, OrderRepository, NotificationRepository и т.д.).В репозиториях опишите методы для выполнения операций с базой данных (чтение, запись, обновление).В методах репозиториев используйте нативные SQL запросы для batchInsert и batchUpdate.Создание наблюдателей и событий:
Для обработки событий создайте классы-наблюдатели и опишите в них логику, которую необходимо выполнить при наступлении определенных событий (например, при изменении статуса заказа).Создайте классы событий, которые будут генерироваться при выполнении определенных действий (например, OrderStatusChangedEvent).Подпишитесь на события в нужных местах приложения (например, в сервисах) и запустите выполнение обработчиков в очереди.Работа с очередями:
Для выполнения длительных операций, таких как отправка уведомлений или обновление кэша, используйте очереди (например, встроенный в Yii2 механизм работы с очередями).Поместите задачи на выполнение в очередь из обработчиков событий, чтобы не блокировать основной поток выполнения.Важно помнить, что при переходе от ActiveRecord к такой архитектуре может потребоваться провести большой рефакторинг кода, но в итоге получится более гибкая и масштабируемая система. Однако, оцените заранее, стоит ли затраченное время и усилия на переписывание текущего кода на новую архитектуру.