Обмен данными между модулями.

СУБД

Мы этого не делаем, но для общения между процессами есть разные IPC, а общения между модулями есть вызовы процедур и методов.

Юзать какой-нибудь Redis как склад, или посмотреть в сторону AMQP. Зависит от того какие данные и как устроено это ваше приложение.

1. Как было уже сказано, СУБД (это большая всех взаимодействий)
2. Мемкеши (redis, memcache и т.п.). Вместе с первым в моих проектах это подавляющая доля взаимодействий. Дальше по мелочи, вне порядка приоритета:

— Сессии (в смысле нативные)
— Файлы (требует особой осторожности)
— Gearman (постановщик задачи закидывает параметры, диспетчер снимает и раздаёт воркерам)
— Вызовы по http (GET/POST)

Может, ещё что-то упустил. Всё от конкретных условий задачи зависит.

независимые друг от друга модули
обмениваться данными. не должны

Какие СУБД? Какие Redis? Похоже я очень коряво выразился...

Передача данных от одного контроллера другому в пределах одного хита. Пример: Есть страница /catalog/galaxy_5s_lumia/ и есть два блока на страницы первый из которых вынимает из базы данные о товаре, а второй отзывы. Отзывы привязаны к ID товара, поэтому чтобы их достать надо по galaxy_5s_lumia найти товар и узнать его ID. Но первый блок, который вынимал данные о товаре, уже достал его ID и глупо нырять за ним в базу еще раз. Его можно передать следующему исполнямому блоку просто через global $ID_TOVARA_POKAZANNOGO_na_thisPage; а можно и не свинячить, а использовать единый глобальный массив для такого обмена или... ?

глупо нырять за ним в базу еще раз

Глупо. Поэтому придумали memcached.

Shared Memory
http://ru2.php.net/manual/en/ref.shmop.php

Semaphore
http://ru2.php.net/manual/en/ref.sem.php

Сделать третий модуль, куда вынести функционал, а в первоначальных двух использовать методы третьего. Третий может быть singleton и хранить в себе данные. При инициализации третий может брать данные из БД/кэша и сохранять их как свойства.

Фреймворк слишком уж абстрактный и вообще модули больше присущи CMS, а не фремворкам.

Передача данных от одного контроллера другому в пределах одного хита.

Тогда прямой вызов методов. Или я вопроса не понимаю :)

есть два блока на страницы первый из которых вынимает из базы данные о товаре, а второй отзывы

Извлечение данных я всегда делаю в едином контроллере объекта. И скармливаю их модулям. Т.е. контроллер один. Оперирует разными моделями и разными представлениями.

Его можно передать следующему исполнямому блоку просто через global $ID_TOVARA_POKAZANNOGO_na_thisPage

Тут без вариантов. Или единая точка извлечения данных в контроллере, или передача глобальных данных. При чём второй вариант опасен — а что если ты местами поменяешь вызов модулей?

...

Вообще, у меня модули часто «умные» (что чревато и порицаемо, но я не идеален :D). Если им поданы на вход данные по моделям — используют их. Если нет — извлекают сами. Соответственно, одиночный модуль с простыми данными тупо выписывается в представление и всё. Если начинаются хитрости, в т.ч. с оптимизацией или межмодульным взаимодействием (скажем, нужно элементы, показанные в одном модуле не показывать в другом), то обычно данные извлекаются в контроллере и подаются при вызове модуля параметром вызова.

лучшее решение — события. посмотри zope.components, zope.interface, zope.events, там питон но идею поймешь

еще есть редиска или что-то более взрослое

тред не читал

вот это плюсую

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

Прямой вызов создаст ненужную зависимость между модулями

Лучше таки gearman/0mq/etc

Лучше таки gearman/0mq/etc

В пределах одного запроса и потока? Мсье знает толк в извращениях :D

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

Тогда почитай хорошую статью про связывание и инициализацию модулей здесь: http://habrahabr.ru/post/183658/

Если хочется еще меньшей связности, ты не любишь хуки, или просто понадобилось «Действие на расстоянии»:
http://symfony.com/doc/current/components/event_dispatcher/introduction.html

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

Но первый блок, который вынимал данные о товаре, уже достал его ID и глупо нырять за ним в базу еще раз.

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

$currentProduct = $this->productLocator->getProduct($productId);

Инстанс $productLocator нужно шарить между модулями. Я бы его шарил через конструкторы модулей в момент инициалиации приложения.

Задача не ясна. Пошел запрос PHP, обмен какими данными вам нужен? В конце запроса все умирает и данные теряются, вам их нужно где-то хранить. Либо мемкеш/redis, либо в key-value, либо просто в рядовую СУБД если нагрузка не предполагается особая.

Вобщем всем спасибо, и хотя ответа на свой вопрос я так и не получил (долго объяснять почему не подходит то или иное решение), но в целом задумался о многих вещах, плюсах и минусах разных подходов и т.п. Кое-что для себя прояснил. Отдельное спасибо KRoN73, Black_Roland и VladimirMalyk.

Отмечу, пожалуй, как решенную.

ты под словом «модули» подразумевал совсем другое.

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