Построение Алгоритма OOP движка, на PHP

Alhazred

Новичок
Построение Алгоритма OOP движка, на PHP

Здравствуйте!
Суть вопроса такова:
В связи с расширением разрабатываемого проекта, решил полностью переписать архитектуру движка сайта, но столкнулся с техническими вопросами, в которых моей квалификации, явно не достаточно.

Из-за непонимания технической части Apache сервера и процессора PHP, оказалось что, я, ну могу даже правильно сформировать поисковый запрос. (((


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

Использую Apache+PHP5+MySQL.
Итак:
Допустим, что, существует сущность rootProcess, класса rootAbsolute, которая является общим и единым непрерывно работающим процессом на сервере, для всех пользователей портала, на текущий момент.

В обязанности rootProcess, входит:
1) обработка команд, поступающих от сущностей-гостей сайта.
2) Ведение единого лога событий.
3) Динамический контроль прав, сущностей-клиентов сайта.
4) Единый процесс аутентификации клиента-пользователя.
5) Возможность динамического зарубливания объекта-клиента, как процесса.
6) Ведение рила тайм лога, активности клиентов сайта с отображением в терминале, доступном через админ панель.
И т.д.

При входе на сайт как гость, клиент, как и должно, имеет ограниченные возможности.
В таком случае rootProcess создает для клиента сущность класса gues
При успешной аутентификации, сущность rootProcess, рубит пользовательский процесс класса gues и создает новый экземпляр объекта (что-то чипа $userProcess или $adminProcess)

Для идентифекацыи и связи клиента-пользователя, с нужным процессом ($adminProcess или $userProcess), сущность rootProcess, использует идентификатор UIN.

Вот здесь и вопрос. Совершенно не укладывается в голове.
1) Каким образом реализовать работу программы, единым процессом, так, чтобы сущность класса rootProcess, могла динамически контролировать все пользовательские процессы, так же, как это, происходит, скажем, при взаимодействии ядра ОС с программным приложением?

2) Укажите, в какой области, лежит дефицит моих знаний?
 

dimagolov

Новичок
Допустим, что, существует сущность rootProcess, класса rootAbsolute, которая является общим и единым непрерывно работающим процессом на сервере, для всех пользователей портала, на текущий момент.
Начни с http://phpfaq.ru/na_tanke, так как приведенная цитата таки демонстрирует полное непонимание того, что есть web-программиирование вообще и на php в частности
 

Alhazred

Новичок
Да, действительно, чего-то я гоню))
Оседаю в офлайн для чтения теории...

Дежурный врач! Спасибо за диагноз.
Тема исчерпана.
 

Духовность™

Продвинутый новичок
Alhazred
1) обработка команд, поступающих от сущностей-гостей сайта.
2) Ведение единого лога событий.
3) Динамический контроль прав, сущностей-клиентов сайта.
4) Единый процесс аутентификации клиента-пользователя.
5) Возможность динамического зарубливания объекта-клиента, как процесса.
6) Ведение рила тайм лога, активности клиентов сайта с отображением в терминале, доступном через админ панель.
И т.д.
в целом правильные мысли. просто надо учесть, что написано на танке. а там написано, что PHP исполнил скрипт и умер.

А вообще вопросы на тему "как сделать движок" ИМХО задавать не стоит, т.к. тема эта слишком обширная и никто тут расписываться особо не будет. Надо конкретизировать вопросы. Чем более конкретный вопрос , тм больше вероятности, что дадут хоть какой-то ответ :)
 

Alexandre

PHPПенсионер
да, это супер-флеймовый вопрос, так как сколько людей, столько и мнений
а мы - люди, очем любим набивать шишки на собственных велосипедах...

мое виденье (не факт что верное)
первое - разбираемся как устроено WEB приложение,
второе - разбираемся как сделать авторизацию и что такое сессия,
третье - пытаемся нарисовать квадратиками свои сущности и определить зоны ответственности...
четвертое - делаем декомпозицию, выделяем общие части и переходим к шагу три....
каждая сущность - это класс, которая наиболее полно должна отражать модель
реального мира
пятое - читаем, что такое MVC и увязываем с пп три и четыре...
выделяем абстрацию: WEBApplication ( приложение ) и WEBPage ( страница )
снова переходим к пп три...
по ходу должны выделится такие абстракции ка BD, Session, Role, User, Permission etc...
ну а дальше - полет фантазии, что непонятно welcome!
 

DarkLordis

Новичок
ох не люблю я сущности/связи и вредное теоретизирование... но по-моему если вопрос очистить от шелухи его решение есть в каждом учебнике по php (было даже в том что я читал в каком-то мохнатом году... php тогда помню был 3) типичная в общем задача авторизации на сайте... простите все это надо было в секцию флэйма
 

Alexandre

PHPПенсионер
ох не люблю я сущности/связи и вредное теоретизирование...
тогда твоя дорога - процедурный подход! Ни кто не говорит, что это плохо, просто: сколько людей - столько мнений...
 

DarkLordis

Новичок
Автор оригинала: Alexandre
тогда твоя дорога - процедурный подход! Ни кто не говорит, что это плохо, просто: сколько людей - столько мнений...
нет. есть разные технологии проектирования.

-~{}~ 28.07.09 14:25:

Alexandre чтоб не получился казус. Я придерживаюсь вашего подхода... но практически приходится начинать с конца. Оперирование понятиями ER по-моему не возможно при первой итерации... Как не странно сталкивался с таким подходом у многих уважаемых авторов.
 

Alexandre

PHPПенсионер
но практически приходится начинать с конца.
есть разные подходы к проектированию: нисходящее и восходящее, по этому иногда приходится начинать с конца. Это нормально!
 

Alhazred

Новичок
Почитал http://phpfaq.ru/na_tanke, как заповедал господин dimagolov, посидел намедни в офлайне, полистал литературки всякой и пришел к такой идее:

Чтобы имитировать динамическое воздействие на процессы клиента, необходима возможность вмешательства в клиентский процесс, что само собой невозможно на PHP.

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

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

Динамический контроль прав, сущностей-клиентов сайта.
(путем изменения сессионного файла, административным скриптом).

Возможность динамического «зарубливания» объекта-клиента, как процесса.
(простое стирание одного или группы сессионных файлов административным скриптом).

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

Благо, при изучении альтернативных способов использование сессий, вспомнилась методика, которая решила все мои вопросы.
Хранение сессий в базе данных.
Эта идея стара как мир. Просто я и не представлял, что с помощью нее, можно решить поставленную задачу.
Использование выше приведенной методики, поможет реализовать следующие задачи:

а) Можно сериализовывать объекты и сохранять их в сессии. Но не в файл, как это делается обычно, а в таблицу базы данных.
б) Административный скрипт, будит иметь доступ к таблице, тем самым имея возможность «убивать» процесс, просто стирая сессию.
в) Также, административный скрипт сможет, динамически десериализовывать
клиентские объекты из сессий, для модификации и обратной сериализацыи с последующей упаковкой в сессию (имитация динамического изменения процессов клиента).
г) Если хранить в таблицах, сессии клиентов по спискам (к примеру, администратор, модератор, пользователь, клиент), то можно без проблем, рубит целые группы клиентов.

Весь процесс, в двух словах думаю оформить так:
1) При запуске скрипта, будит создаваться базовый объект, конструктор которого сравнивает UIN обратившегося клиента с UIN'ами, чьи записи, хранятся во временной MySQL таблице.
2) Если UIN имеется, то читаем из таблицы сериализованый объект (продолжаем сессию клиента). Если UIN отсутствует, значит, создаем базовый объект для клиента.
Вот нарисованный алгоритм:
http://www.valar.ru/upload/jpg/0809/1249425877_2.htm


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

Вопрос к тем, кто использовал подобное решение.

1) Насколько велика нагрузка на MySQL.
2) Какой тип таблиц лучше здесь использовать.

Или может быть, опять идти в офлайн для чтения))))))

-~{}~ 05.08.09 03:38:

Господин Alexandre!
Так в том и суть, что проект слишком большой получился, для процедурного подхода. Туплю в собственном коде.

Началось все с неправельного использования ООП (в этом проекте, использовал ООП, лиш для наглядного структурирования), в итоге, мне сложно теперь проект дальше двигать.
То лень и предвечный копипаст.

Решил, класть проект, на миханизм нового движка,
используя правельную методику ООП.
 

AmdY

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

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

tf

крылья рулят
Но ведь клиентский процесс на сервере, это не только исполнение инструкций скрипта, но и файлы сессий.
а нафиг?, ты так и не дочитал на танке http://phpfaq.ru/na_tanke#start
у тебя есть к примеру id пользователя, скрипты отвечающие за работу могут его проверить и умереть, не выполнится - очистив все свои данные
убивать ничего не надо
 

Alhazred

Новичок
Господин tf!

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

Разумеется, информация такого рода, должна храниться в сессии.

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

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

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

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

Модератор сможет очень гибко и динамично изменять (или не изменять) данные сессии клиента, чтобы клиент, и плюнув и выругавшись, прекратил маяться глупостями


Кстати что-то схожее используется в ASP.NET и называется "Внепроцессное состояние сеанса"
 

zerkms

TDD infected
Команда форума
Разумеется, информация такого рода, должна храниться в сессии.
Лишь в таком случае (я другого способа не нашел)
ты не нашёл другого способа потому, что не попытался оспорить заведомо ложный посыл из первого предложения, который предваряется аксиоматичным "разумеется".
 

tf

крылья рулят
Пусть этой деятельностью будит поиск и установка в плей лист, потокового видео, от различных пользователей соц. сети.
и что? проверить статус невозможно?
zerkms, помоему у нас с ним односторонния связь
Alhazred, а ну ка просвети что такое файл сессии и для чего он нужен?
 
Сверху