Xpoint
   [напомнить пароль]

Взаимодействие модулей в модульном движке

Метки: [без меток]
2005-05-18 15:15:53 [обр] 1m.dm(0/6)[досье]
сообщение промодерировано

Есть модульный движок. Некоторым модулям необходимо взаимодействие. Например, какая-то страница должна быть доступна только зарегистрированным пользователям. Модуль данной страницы должен проверять, залогиненный ли юзер и взависимости от результата проверки - пускать или не пускать.
В своей разработке я сделал пока следующее: все модули реализующие текущую страницу видны в глобальном пространстве как $mod_modname (например, $mod_user - это объект класса Mod_user).
Вариант взаимодействия на данный момент таков. Скажем, модулю mod_cpanel нужно проверить что залогиненный юзер есть админ. Он делает:

if ($mod_user->get_rights() & USER_RIGHT_ACCESS_CPANEL)
{
   // grant access
}
else
{
   // show stop-message
}

ВОПРОС: может есть какие-то боле красивые варианты взаимодействия модулей в модульной системе?

Заранее благодарен.

спустя 50 минут [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]
М Есть подозрение, что тема более общая, чем PHP
спустя 35 секунд [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]
М Перенесено из форума "Программирование::PHP"
спустя 4 дня [обр] dacuan(0/7)[досье]

У меня в последнее время "бродит" мысль о взаимодействии модулей.
На данном этапе есть общие наброски. Будет интересна конструктивная критика.

Итак, система делится на ядро и модули. Ядро представляет собой объект класса, который создается в начале каждого скрипта. Все модули взаимодействуют посредством пересылки сообщений друг другу через ядро. Каждый модуль знает какие сообщения он может обрабатывать и информирует об этом ядро при установке, т.е. у ядра есть таблица обработчиков событий.

Методы ядра:
 - send_msg($msg_id, $param_1, $param_2, ...) - отправка сообщения через ядро, возвращает результат работы модуля
 - install_mod($mod_name, $msgs) - регистрация модуля в системе
 - uninstall_mod($mod_name) - удаление модуля из системы
 - is_mod_installed($mod_name) - проверка установлен ли модуль

У каждого модуля есть метод handle_msg($param_1, $param_2, ...), обрабатывающий события переданные ему ядром.

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

Минусы подхода, которые я вижу:
- ограничение на вызов методов модуля и возвращение параметров, возвращение возможно только через return ...;
- потеря производительности за счет множества промежуточных вызовов функций.

Жду комментариев сообщества.

спустя 20 часов [обр] Андрей Новиков(16/1242)[досье]
dacuan[досье], я не ослышался? Вы хотите в скриптах, которые работают доли секунды, использовать событийную модель и все эти навороты?
спустя 1 час 11 минут [обр] dacuan(0/7)[досье]
Андрей Новиков[досье]
Именно так. Я хочу обкатать модель и помотреть что из нее получится. В перспективе ее можно будет перенести и на Си.
Проблема, которая может возникнуть в скриптовом языке — время выполнения, но будут ли издержки настолько критичными, что придется отказаться от такой архитектуры, думаю, покажут только эксперименты.
Есть ли еще проблемы, реализации подобного подхода к модульности кроме времеи выполнения?
спустя 4 часа 23 минуты [обр] Виталий Верхов[досье]
А если для этого использовать, скажем, mod_perl? Должно не так уж и тормозить
спустя 7 дней [обр] Дмитрий Котеров(15/912)[досье]
"Событийная модель" имеет весьма малое отношение к "быстродействию скрипта", вообще-то. Это просто метод написания кода. Тут, насколько я понимаю, вообще речь идет не о производительности, а о архитектуре. Зачем все вопросы мешать в одну кучу?
спустя 10 часов [обр] dacuan(0/7)[досье]
Дмитрий Котеров[досье]
Думаю, если "событийная модель" будет "безбожно тормозить", то ее использование оправданным не будет, не смотря на всю ее стройнисть и красивость. Поэтому и интересно узнать о всех ее недостатках, да и о достоинствах тоже ;)
спустя 5 часов [обр] Дмитрий Котеров(15/912)[досье]
Да не может "модель" "тормозить". У нее тормозов нет, да и колес тоже. Тормозить может конеретная реализация модели, в зависимости от того, насколько криво она написана.
спустя 1 день 20 часов [обр] dacuan(0/7)[досье]
Невозможно бесконечно оптимизировать реализацию модели. Рано или поздно упремся в физический предел, будь это скорость интерпретации скрипта или какие-либо внутренние тормоза интерпретатора.
Поэтому перефразирую вопрос:
На сколько может падать производительность системы при реализации ее на PHP с использованием "событийной модели"?
Что-то подсказывает мне, что ответ дадут только эксперименты, но может кто-то уже интересовался этим вопросом, о чем и спрашиваю.
спустя 2 дня 13 часов [обр] Дмитрий Котеров(15/912)[досье]
Падать - по сравнению с чем?
спустя 9 часов [обр] dacuan(0/7)[досье]
Падать по сравнению с другими архитектурами взаимодействия модулей. Например, с той, которая описана в первом посте.
спустя 6 часов [обр] Дмитрий Котеров(15/912)[досье]
Нельзя этого оценить.
спустя 16 часов [обр] GRAy(0/259)[досье]
Нельзя оценить кроме как эмпирически ;)
спустя 3 часа 9 минут [обр] dacuan(0/7)[досье]

Дмитрий Котеров[досье]

Нельзя этого оценить.

GRAy[досье]

Нельзя оценить кроме как эмпирически ;)

Можно оценить и эмпирически и аналитичекси, есть же понятие вычислительной сложности алгоритма ;).
Была надежда найти готовое сравнение.

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

спустя 8 минут [обр] Дмитрий Котеров(15/912)[досье]
Вычислительной сложности алгоритма.
То, о чем выше речь, - не алгоритм.
Используйте энциклопедию.
спустя 17 минут [обр] dacuan(0/7)[досье]

Дмитрий Котеров[досье]
Да, это не алгоритм, но определить количество элементарных операций (ЭО), которое будет выполняться при каждом обращении к модулю, возможно. И возможно вывести закон изменения количества ЭО в зависимости от числа модулей, количества функций в каждом из них и числа параметров, передаваемых при каждом вызове.

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

Отсюда и интерес к различным методам организации межмодульного взаимодействия.

спустя 20 часов [обр] Андрей Новиков(16/1242)[досье]
Дмитрий Котеров[досье], Вы считаете использование событийной модели в веб-скриптах оправданной или Вам в очередной раз захотелось позубоскалить?
спустя 1 час 29 минут [обр] dacuan(0/7)[досье]
Андрей Новиков[досье]
Как я понял, Вы считаете использование событийной модели в веб-скриптах недопустимой.
На чем основывается такая точка зрения?
И если событийный подход недопустим, то какую архитектуру советуете использовать Вы?
спустя 1 час 13 минут [обр] Дмитрий Котеров(15/912)[досье]
Андрей Новиков[досье], по какому поводу наезжаем? Или просто настроение плохое?
спустя 2 минуты [обр] Дмитрий Котеров(15/912)[досье]
По поводу вопроса. Я считаю, что пересекать понятия "событийная модель" и "веб-скрипты" - все равно, что сравнивать теплое с зеленым. Одно другое не может исключить в принципе - потому что области разные. И вполне возможна ситуация, когда событийная модель очень даже хорошо применима в веб-скриптах - почему бы и нет?
спустя 2 часа 39 минут [обр] Андрей Новиков(16/1242)[досье]

Дмитрий Котеров[досье], да, когда мы будем программировать усилием мысли, а компьютеры будут рендерить изображения с миллиардами полигонов и сотнями источников света за долю секунды, мы конечно будем использовать событийную модель в веб-скриптах. А на данный момент я не представляю, зачем городить этого монстра для вывода 10 килобайт текста в течение 15 миллисекунд. Правда я хреновый программист, и возможно Вы знаете, как реализовать правильную событийную модель на текущих скриптовых языках в десятке строк кода, и чтоб КПД программы не приближался к 10%.

dacuan[досье], классическую — вызов методов объектов или функций, если не заморачиваться ООП.

спустя 2 часа 9 минут [обр] dacuan(0/7)[досье]

Андрей Новиков[досье]

классическую вызов методов объектов или функций, если не заморачиваться ООП.

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

спустя 10 минут [обр] Андрей Новиков(16/1242)[досье]
Да, зато повышает производительность и прибыльность. Скажу Вам по секрету, проект любого уровня, который осуществляется любым из посетителей Xpoint вообще не требует никакой архитектуры, модульности, концептуальности. Их надо делать плоско, тупо, на PHP или ASP. Архитектура требуется для сайтов типа Яндекса, Гугла, Майкрософта и т.п. А то, что мы тут все умничаем со всякими движками, архитектурами и прочим — это всё от скуки и перфекционизма.
спустя 4 минуты [обр] Дмитрий Котеров(15/912)[досье]

Еще раз: вопрос быстродействия относится к алгоритму, а чаще всего - к степени кривизны реализации этого алгоритма. И оценивать быстродействие тоже можно только для алгоритма. Событийная модель - это не алгоритм. В той или иной степени она применяется в куче систем — например, взять тот же SAX парсер, set_error_handler() в PHP, исключения (тоже, между прочим, "событийная модель" в каком-то смысле) и т.д. Если ее использование делает код прозрачным и легко расширяемым - надо ее и применять.

Скрипт, кстати, далеко не всегда занимает 10К, и далеко не всегда работает доли секунды. По крайней мере, в мире, где "программируют не устилием мысли, а компьютеры ... (далее по тексту)". Я считаю так: не стоит экономить на спичках, предполагая, что накладные расходы на вызов пары сотни функций-посредников вдруг внезапно превзойдут все остальные накладные расходы, обычно имеющиеся в скриптах (чаще всего - работа с БД и трансляция кода во внутреннее представление).

спустя 5 минут [обр] Дмитрий Котеров(15/912)[досье]
И еще мне не нравятся, когда web-программирование выставляют в виде обезьяньего труда - тупого и "плоского" кодирования.
спустя 1 час 10 минут [обр] dacuan(0/7)[досье]

Дмитрий Котеров[досье]
В своем первом посте я дал четкое описание той архитектуры, мнения о которой меня интересуют. Если честно, в данный момент времени меня абсолютно не интересует качество реализации обмена событиями в SAX, WinAPI и прочих пограммных продуктах. Можно бесконечно искать истину и дискутировать на тему "абстрактности модели и множества ее воплощений", но это будет лишь пустой разговор без возможности получить какие-либо конструктивные результаты.

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

Андрей Новиков[досье]

Скажу Вам по секрету, проект любого уровня, который осуществляется любым из посетителей Xpoint вообще не требует никакой архитектуры, модульности, концептуальности. Их надо делать плоско, тупо, на PHP или ASP .

Я безумно счастлив за большую часть посетителей Xpoint, но писать "плоско" и "тупо" душа не лежит. Уж не обессудьте.

спустя 2 часа 2 минуты [обр] GRAy(0/259)[досье]
dacuan[досье] ИМХО Вы предлагаете обсудить отсутсвие модели и её наличие ;) Идеально написаный код не основывающийся ни на какой модели будет работать быстрее хорошо написанного кода без этой самой модели т.к. модель всегда подразумевает некоторый оверхед. Просто без модели написать идеальный код будет на порядок сложнее.
спустя 2 минуты [обр] GRAy(0/259)[досье]
извиняюсь... ;) в предыдущем постинге читать так:
Идеально написаный код не основывающийся ни на какой модели будет работать быстрее хорошо написанного основанного на модели...
спустя 12 часов [обр] Андрей Новиков(16/1242)[досье]

Дмитрий Котеров[досье], мало ли кому что не нравится. Но есть еще и экономическая обоснованность.

dacuan[досье], не надо обижать посетителей Xpoint. Я говорил лишь только об обоснованности.

спустя 57 минут [обр] Андрей Пахомов(0/310)[досье]

Андрей Новиков[досье]

 А то, что мы тут все умничаем со всякими движками, архитектурами и
прочим — это всё от скуки и перфекционизма.

ИМХО, все таки этим люди занимаются как раз не от скуки, а от того, что это экономически выгодно. Отсутствие какой либо архитектуры или модульности обрекает программиста на постоянное переписывание либо copy-past своих решений из проекта в проект, что отнюдь не повышает его экономическую эфективность. А от того что "тупой" и "плоский" стиль программирования присущ новичкам отнюдь не делает его стандартом веб-разработки. Другое дело, что реализовывать что то совсем изощеренное на случай "а вдруг пригодится" и без насущной на то необходимости я смысла не вижу.

спустя 5 часов [обр] dacuan(0/7)[досье]

Андрей Новиков[досье]
Я глубоко извиняюсь перед посетителями Xpoint, если кого-либо задел мой пост, но он был лишь ответом на Ваше более чем критическое замечание о нелюбви этих самых посетителей к концептуальному подходу в веб-программировании.

GRAy[досье]

ИМХО Вы предлагаете обсудить отсутсвие модели и её наличие ;) Идеально написаный код не основывающийся ни на какой модели будет работать быстрее хорошо написанного кода без этой самой модели т.к. модель всегда подразумевает некоторый оверхед. Просто без модели написать идеальный код будет на порядок сложнее

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

Так что использовать модель рано или поздно придется, осталось только выбрать какую и как.

спустя 5 месяцев [обр] Libov[досье]
Я вообще строю код по порядку его исполнения, вычисляя необходимый мне модуль на каждом этапе. В результате практически создается просто короткий наборный модуль. Если какие-то переменные не определены (не залогинился, уровень доступа или пр.) - то и не включаются в поток интерпритации отсутствующие модули. Результат сборки модулей и начальных значений в конце в виде структуры укладывается в сесию. После повторного вызова - выбирается из сессии и используется для построения следующего сборного модуля..
И так постоянно, пока пользователь не закроет браузер.
Powered by POEM™ Engine Copyright © 2002-2005