LINUX.ORG.RU

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

 ,


0

1

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

А как еще вы это делаете?

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

tailgunner ★★★★★ ()

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

genesis_error ()

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

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

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

KRoN73 ★★★★★ ()

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

metrokto ★★ ()
Ответ на: комментарий от KRoN73

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

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

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

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

anonymous ()

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

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

Black_Roland ★★★★ ()
Последнее исправление: Black_Roland (всего исправлений: 2)
Ответ на: комментарий от Suntechnic

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

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

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

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

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

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

...

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

KRoN73 ★★★★★ ()

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

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

тред не читал

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

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

trashymichael ★★★ ()
Последнее исправление: trashymichael (всего исправлений: 1)
Ответ на: комментарий от KRoN73

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

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

boombick ★★★★★ ()
Ответ на: комментарий от boombick

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

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

KRoN73 ★★★★★ ()

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

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

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

VladimirMalyk ★★★★★ ()
Ответ на: комментарий от boombick

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

VladimirMalyk ★★★★★ ()
Ответ на: комментарий от Suntechnic

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

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

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

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

VladimirMalyk ★★★★★ ()

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

umren ★★★★★ ()

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

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

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

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

alexmaru ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.