BoShurik

AJAX

Подобная задача решается через т.н. брокеры сообщений (Message broker). Есть несколько возможных вариантов, к примеру выделенные сервера, реализующие протокол AMQP (например RabbitMQ, ActiveMQ и другие), стриминговые сервера (к примеру Kafka), сервисы очередей (Amazon SQS и подобные), а также другие реализации паттерна PubSub, к примеру в Redis.

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

В вашем сценарии скорее всего будет подразумеваться две очереди:

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

Возможно есть ещё какие-то задачи и реальная схема будет сложнее, но в целом, надеюсь, идея понятна.

Для PHP существуют немало binding'ов к серверам, реализующим message brokering. Не знаю что именно на сервер вы выберете, поэтому навскидку приведу php-amqplib/php-amqplib для работы с AMQP (в первую очередь с RabbitMQ), enqueue/amqp-tools (также для AMQP) и superbalist/php-pubsub для реализации PubSub паттерна, к примеру через Redis.

Вы не указали на чём написан ваш проект, но в целом также можно посмотреть в сторону компонента Messenger для Symfony, его можно использовать и вне Symfony и он даёт хорошую базу для реализации схем обмена сообщениями.

У меня есть опыт такого подхода.

Symfony это фреймворк который состоит из набора компонентов и интеграционного слоя. Symfony выделяет отдельные компоненты в отдельные репозитории для того, чтобы их можно было использовать независимо от фреймворка.

Не думаю что у вас есть в это особая необходимость. Но вы можете разработать какие-то свои компоненты и вынести их в отдельные репозитории и устанавливать как зависимости. Можно даже сделать их open source и сообщество может вам помогать в их разработке и сопровождении.

Как и сказал BoShurik, бандл это уровень интеграции компанента в фрайморк. Выделяя компонент в отдельный репозиторий вам нужно и бандл выделять в отдельный репозиторий. Так у вас будет 2 отдельных git репозитория.

Таким образом у вас будет следующие git репозитоии:
- ядро проекта
- компонент блога
- бандл блога
- компонент мероприятий
- бандл мероприятий
- компонент деятелей
- бандл деятелей
- компонент аккаунта
- бандл аккаунта
и др. х2

Разделение проекта на много независимых репозиториев это не есть плохо. Как и разделение проекта на микросервисы. Но у этого подхода есть существенный недостаток. Часто нужно внедрять новые фичи или править баги которые требуют внесения изменений в несколько репозиториев одновременно. Это доставляет массу неудобств. Особенно когда нужно проходить через этап релиза. Протестировать в проекте работу правок можно только после внесения их в бандл и релизе его, а зарелизить бандл можно только после его тестирования, а тестирование бандла требует тестирования и релиза компонента, а делать релиз компонента не убедившись как оно будет работать в конечном продукте нельзя. В общем релизный ад. Я проходил через него и не советую другим. Это осмысленно только для больших проектов с большой командой разработчиков.

Как и сказал BoShurik, разделяйте проект на независимые модули и организуйте модули в папки и неймспейсы. Я пользуюсь этим методом уже несколько лет. Полет нормальный.

App/Blog/Controller
App/Blog/Entity
App/Events/Controller
App/Events/Entity

Разработчики Symfony зря советуют не использовать бандлы. Ваши модули по сути и будут бандлы. Вы создаёте в модуле бандл в котором описываете метод интеграции модуля с фреймворком.

App/Blog/AppBlogBundle
App/Events/AppEventsBundle

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

Касательно того как всё устроено конкретно в Symfony. Я довольно давно изучал этот вопрос и могу ошибаться в деталях.
В Symfony когда-то использовался git submodules для компонентов. Но от этого решения отказались. Оно не очень удобное, особенно для конечного пользователя. В плане разработки это чуть удобнее чем отдельные пакеты на мой взгляд.
Сейчас всё работает иначе. Есть основной репозиторий symfony/symfony. Все компоненты находятся в нем. Всё правки вносятся в него. В репозиториях компонентов никакой активности нет. При коммитете или пуше в ветки symfony/symfony запускается хук который на отдельном сервере SensioLabs запускается специальная утилита которая копирует все коммиты сделанные в компонентах из symfony/symfony в репозитории соответствующих компонентов. Мне как-то попадался сайт SensioLabs на котором можно было скачать эту утилиту.
Суть в том, что это не репозиторий Symfony состоит из репозиториев компонентов. Это компоненты Symfony по сути выдранные куски кода из основного репозитория.

Я когда-то тоже хотел сделать приложение с выделенными модулями в отдельные репозитории как у Symfony, но разобравшись в вопросе я пришел к выводу, что мне это не подходит. И вам думаю тоже не подойдёт.

Нет, только если в аннотациях

/**
 * @param string|int $a
 */
function test($a) {}

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

В целом, если вы хотите получше разобраться в паттернах проектирования - можно брать любую хорошую книжку по этой теме (те же Gang of Four, Мартин Фаулер (на русском) и т.п., предложенная Ярослав ссылка тоже выглядит весьма достойно), изучать, а затем пытаться найти эти паттерны в коде популярных и хорошо написанных проектов.

Я несколько предвзят, но могу порекомендовать Symfony и Doctrine в качестве отправных точек. К примеру та же Doctrine прямо реализует целый пласт паттернов, описанных Фаулером. Symfony существенно более разнообразна, там можно встретить много различных решений.

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

Есть метод калькуляции заказа. Метод нужен во многих местах.

в этом и ошибка - все в кучу. Надо сделать, что бы калькуляция была не черным ящиком, а настраиваемым удобным интерфейсом:

$discountCalculator = new discountCalculator(\ListItems $items);
$discountCalculator->addCondition(new SimpleDiscount());
$discountCalculator->addCondition(new BlackFridayDiscount());
$discountCalculator->addCondition(new ByDateDiscount('last day of this month'));
$discountCalculator->addCondition(new ApiDiscount());
$discountCalculator->calculate();

Делайте дамп $notice->getUser(), там всё будет. Это ленивая загрузка доктрины

В Mongo Aggregation можно сделать через временный массив.

1. Сортируем все документы в порядке убывания rating и active (позиция будет расти сверху вниз)
2. $push всех отсортированных документов во временный массив data
3. Создание нового массива arr и внесение в него всех элементов массива data в том же порядке, но добавляя поле position, которое формируется исходя из положения объекта в массиве data ($indexOfArray)
4. Разбиение ($unwind) массива arr на обычный список документов, но уже отсортированный и с проставленными position
5. Преобразование документов после разбиения к нужному виду

db.getCollection('testo').aggregate([
    { $sort: { rating: -1, active: -1 } },
    { $group: { _id: null, data: { $push: "$$ROOT" } } },
    {
        $project: {
            arr: {
                $map: {
                    input: "$data", as: "e", in: {
                        rating: "$$e.rating", 
                        active: "$$e.active", 
                        position: {
                            $add: [{ $indexOfArray: ["$data", "$$e"] }, 1]
                        }
                    }
                }
            }
        }
    },
    { $unwind: "$arr" },
    { $project: { 
        _id: 0,
        rating: "$arr.rating", 
        active: "$arr.active", 
        position: "$arr.position" } }
])

Если версия MongoDB довольно старая, то придется вручную вписывать все поля, которые нужно учитывать в массиве. Если же версия новая, можно дополнить действием $mergeObjects. Также есть вариант использовать более сложные схемы ($arrayToObject, $objectToArray) для сохранения полей при переходе массива из одного состояния в другое

Setup::createAnnotationMetadataConfiguration($entitiesPaths, $isDevMode, null, null, false);

для доктрины до версии 3.0(в третьей версии вроде бы сделают по нормальному). Скорее всего проблема в том, что в проекте на Symfony вы в аннотациях пишете что-то вроде @ORM\Entity, а для этого чистой доктрине нужно подсунуть нормальны AnnotationReader, а не Simple который по дефолту создается.

Если тег Symfony не просто так:
$request->request->get('user')[name];

Источник: https://symfony.com/doc/current/components/http_fo...