IsaevDev: beanstalkd вроде как умеет откладывать выполнение задачи по таймеру.
То есть мы ложим в beanstalkd задачу с пометкой "отложить на 30 минут" и в задаче указываем что делать и т.д.
В то же время у нас все время висит воркер (на php) который ждет задач от beanstalkd. Он подключен к нему как обычный клиент и ждет. Поскольку мы положили отложенную задачу он получит ее только через 30 минут (или позже на пару секунд если воркер был занят другими задачами).
Atllantis: давайте так. "крайне не рекомендуется" - это стериотип. Вполне себе можно, сдобрив сверху supervisord-ом каким и ограничив лимит по памяти на случая течки (иногда случается, так как похапэшники не сильно запариваются о таких вещах). Но в целом у меня вот скриптики месяцами крутятся и все хорошо. Перезапускаются только при деплое.
ну и да - очередь то скорее всего на чемт-то надежнее написано и воркеры как были stateless так и остаются.
AndNovak: тип того. Ибо появится у вас "монитор" отдельно и куда его пихать? А так у нас есть одна единственная сущность "product" и мы храним ее в каталоге. А то что один продукт может на другой ссылаться - это уже такое.
NeoCode: короче вам нужна книга-книг по фреймворкам которая объективно их оценивает - таких нет. Это как искать объективную оценку 5-ти конкурирующих продуктов. Вы такой не найдете или она не ответит на все ваши вопросы.
К сожалению нужно пробежаться по документации фреймворков (обычно есть что-то типа getting started или big picture). Качество документации к слову тоже стоит учитывать.
не фотография лайкает юзера, мы отправляем фотографии сообщение о том что кто-то ее лайкнул и передаем в качестве параметров сообщения кто собственно лайкнул. Собственно я обычно когда парюсь пишу как раз таки $photo->likedBy($this->getUser());
Потому что главным объектом выступает все же $photo а не $user.
> посмотреть, а лайкнул ли этот юзер уже эту фото?
это можно сделать проверив есть ли такой юзер по связи, я уже расписывал про extra lazy и matching.
> а может ли он это делать? (может проверяться до)
это либо делается прямо внутри метода (если данных достаточно) либо на уровень выше.
> а если лайнкул поставить дизлайк?
дизлайк это отсутствие лайков. Ну либо это просто будет изменение оценки, то есть удаляем старую оценку и добавляем новую.
Но все же поясню для остальных чем плохо то что юзер знает о лайках. Посты или там фотки (или любая сущность с Likable) должна знать о лайках тоже... ну мол что бы количество лайков выводить удобно. И тогда у нас появляется двусторонняя связь между сущностями. Это как циклическая зависимость но чуть менее страшно. Просто приносит порой боль.
> у каких фреймворков архитектура "топорная" а у каких нет, и не переписывать проекты много раз, мне и нужно общее представление о построении фреймворков как таковых
Не правильная предпосылка. Выбирать нужно исходя из тех целей, для которых задумывался фреймворк. Например есть Zend, который писался с оглядкой на лучшие практики в индустрии, которые помогают делать большие проекты. Symfony который предоставляет возможность использовать как и эти практики, так и многое упростить. Laravel так же - все то же что и в Symfony но уровень надежности приложений намного ниже (и этого хватает для 95% проектов). Yii - упор на быструю разработку и в жертву принесено масштабирование. То есть если вы взяли Yii у вас уже не выйдет "отделить" ваш код от фреймворка.
И самое интересное, если вы будете понимать что такое "связанность" кода и чем гразит слишком высокая связанность от фреймворка - то вам достаточно будет 20-ти минутного просмотра документации к фреймворку что бы определить слабые места.
Например Yii и Laravel-вский Eloquent заставляют нам в наших "модельках" наследоваться от системных классов, что по умолчанию завязывает имплементацию на оные и мы уже никуда не денимся. Для подавляющего большинства проектов это нормально, но для малого процента проектов которые могут пережить фреймворк - это уже не очень то удобно.
> Например тот же ORM - а нужен ли он мне вообще? Может лучше написать вручную models, выполняющие конкретные задачи с БД
опять же, вы путаете ORM и ActiveRecord/DataMapper/DAO. ORM - это связи между объектами (Object Relational Mapping) в то время как ActiveRecord/DataMapper/DAO - это просто разделение ответственности по хранению данных. Рекомендую в этом плане Фаулера почитать - Шаблоны проектирования энтерпрайз приложений.
А то что у ваш там "некоторый стиль мышления" - опишите его. Возможно вам просто надо CRUD-ы фигачить а тут как бы что угодно сойдет.
staffID: если у вас "деревья" только на чтение, то есть нет сложных выборок то можно хранить их просто как adjacency list + materialized path. И это тоже будет эффективно. А если нужно учитывать связи между элементами то эффективно будет хранить это в виде графа и использовать соответствующие инструменты.
copal: если человек в состоянии изучить JS то я думаю с PHP он тоже справится на таком уровне. Ну и да - PHP очень плохой шаблонизатор. Если разработчики не используют какие-либо шаблонизаторы с автоматическим экранированием вывода они скорее копают себе яму. Причем это и к JS-у относится.
