Шаги к MVC или как правильно (или неправильно) сделать проект

Alexandre

PHPПенсионер
Шаги к MVC или как правильно (или неправильно) сделать проект

Идеалогия построения WEB-проекта:

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

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

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

Каждый модуль представляет собой класс, произведенный от австрактного класса TModule
Каждый модуль имеет внешнее представление ввиде шаблона (я исп. XSLТ но можно и Smarty)
На один модуль один шаблон. Шаблон имеет имя, соответствующее имени модуля, но др. расширение *.xsl и лежит в отдельном каталоге /xsl
При необходимости, шаблон может иметь *.ini файл, имя которого соответствует имени модуля с др. расширением,
но сам *.ini файл лежит в каталоге /ini

По этому же принципу могут быть файлы css и js

Общая структура проекта приблизительно такая
..
/images
/xsl
/ini
/css

*.php

Подробнее об class Users extend TModule {} :

Класс имеет методы, которые соответствуют действиям. Действия (actions) выполнябтся над "субъектами", например Модуль "Пользователи" содержит все действия:
( регистрация, редактирование профайла, удаление) которые соответствуют action = reg, action = edit, action = delete.

При получении модулем каждого действия, происходит его анализ и запускается соответствующий метод, т.е. в нашем случае класс должн содержать методы:
- reg
- edit
- delete.

Соответственно в HTML формах должны быть скрытые поля пример: <input type=hidden name=action value=edit>
в ходе выполнения конкретного метода, формируются данные, которые потом оборачиваются в структуру:
<root>
<action error=[сообщение об ошибке]>[name method]</actiom>
<xmlData> ....</xmlData>
<root>
Так же в теге <root> может содержаться иная пользовательская или служебная информация в качестве аттрибутов.

Модуль каждого Xsl файла вызывают:
1) общий для всех страниц шаблон
2) шаблон метода, который указан в <action>[name method]</actiom>

метод print объекта TModule осуществляет:
- вычисление полного имени файла (поддиректории /xsl) шаблона
- парсинг
- вывод
 

chameleon

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

как я уже где-то писал, у себя сделал парсинг шаблона текущей страницы в котором вылавливаю xpath'ом все модули аля
PHP:
<module name="news"><param name="count">12</param></module>
насколько "идеологически" правильно незнаю :)...пока ни одни грабли не стрельнули :)..
и по этому nodeset'y циклом подключаю модуль...

вспомогательных и ini файлов.
какого рода настройки там хранятся? почему не БД?
 

_RVK_

Новичок
содержащийся в одном файле
Зачем в одном? Пихать все в один файл....
У меня похожая структура CMS, но один модуль это много файлов, лежащих в отдельной папке. В этой же папке лежит ini с именем модуля. Для всех модулей доступны общие классы и билиотеки, конмтрктор форм, шаблонизатор и т.д.

И еще, создавать обект TModule, ИМХО, лишнее разбозаривание ресурсов.
 

Alexandre

PHPПенсионер
Зачем в одном? Пихать все в один файл....
тема у меня называется:
как правильно (или неправильно) сделать проект
может я делаю неправильно? - но у меня все работает и я доволен!

можно разбить все работы с субъектами по папком
а действия по разным файлам. в папку запихнуть и js, и xsl
тогда:
переход от модуля к модулю возможен через Redirect, что не всегда хорошо и затрудняет передачу переменных, которые надо записывать в сессию:
Например поле выполнения метода add() надо выполнить метод edit() - и таких вещей несколько...

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

Достоинство - быстро находишь то -что ищешь
 

_RVK_

Новичок
Alexandre
Недостаток твоего метода гораздо глубже. Читабельность твоих модулей падает в разы. Что бы что то искать нужно знать как это выглядит. В твоем же коде, черт ногу сломит. Никто другой, кроме тебя не станет даже пробовать разобраться.
Второе, неправильно пытаться всунуть в ООП все что можно. Вызов метода раза в 2 медленне вызова функции+создание обекта+память на хранение объекта, но в большенстве своем не нужно даже функций. В этоге получатся совершенно не универсальные классы, по одному на модуль. ИМХО, нет в этом смысла. Главное нет приемущества, перед обычным способом.
 

Screjet

Новичок
Вопрос на засыпку: если нужно будет к этому чуду прицепить дизайн/красоту: то как это сделать?
Cможет ли это сделать человек далекий от php, smarty, xsl ?
 

chameleon

Новичок
человек далекий от php, smarty, xsl ?
эт хто? художник-натуралист чтоль? :)...
если скажем веб-дизайнер-верстальщик, то перевести в xslt (x)html-шаблон самому или обучить его метатегам как 2..нет 3 байта...
 

Alexandre

PHPПенсионер
В этоге получатся совершенно не универсальные классы, по одному на модуль
почему по одной на модуль, три-пять неменее (среднее кол-во action на модуль) а то и с десяток наберется

-~{}~ 27.08.04 17:54:

Вопрос на засыпку: если нужно будет к этому чуду прицепить дизайн/красоту: то как это сделать?
Cможет ли это сделать человек далекий от php, smarty, xsl ?
когда я работал в интернет агенстве, наш верстальщик смог разбираться в смарти,
а потом:
общий шаблон (на все страницы) - делает однозначно он
а частные шаблоны (постраничные) - делаю я, а он наводит красоту (в мои теги расставляет стили. )

Ну и последнее - ему за это деньги платят, чтоб в шаблонах разбираться
 

_RVK_

Новичок
почему по одной на модуль, три-пять неменее
Так это еще хуже. Если можно легко обходится без них! Конечно дело хозяйское, но я бы не стал использовать ООП для таких задач. PHP!=Java!
 

Alexandre

PHPПенсионер
интересует вопрос подключения модулей только при необходимости...
как я понял из поста Контроллер подключает все модули, которые видят все данные (а-ля broadcast).... впоследствии уже каждый модуль решает нужны ему какие-либо данные из запроса пользователя или нет
Если подрузумевать под понятием Контроллер - страниц, то как таковой он у меня отсутствует.
я вызываю страницу конкретную index.php, clients.php ....

если подразумевать под понятием Контроллер действий (action), то здесь класс используется на 25-45%,
т.е. при каждом действии отработки страницы используется три-четыре класса, например:
$page->init()
$page->edit()
$page->update()
$page->print()

соответственно
$page->delete()
$page->add()
отрабатывают при выполнении действий delete или add




какого рода настройки там хранятся? почему не БД?
специфические для проекта хранятся в index.ini
там прописывается подключение
специфические одноразовые настройки проекта

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

IntenT

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

А уж применение тех или иных паттернов от языка вообще не зависит.

Так что думай, прежде чем писать, а еще лучше - вместо.
 

Alexandre

PHPПенсионер
впоследствии уже каждый модуль решает нужны ему какие-либо данные из запроса пользователя или нет...
chameleon именно эта идея, анализируются данные пользователя и используется тот или иной метод

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

с другой стороны пхп имеет весь набор функций для программирования WEB приложений, т.к. для этого и разрабатывался
В стандартном ЯВА АПИ многих специальных функций для программирования WEB приложений просто нет (как впрочем и в .NET) но есть масса пакетов которые реализуют эти функции
 

ForJest

- свежая кровь
А уж применение тех или иных паттернов от языка вообще не зависит.
Зависит, ещё как зависит. В случае PHP многие паттерны не нуждаются в абстрактнтых классах вообще. Очень много в патернах делается только для того, чтобы привести всё добро к удобному наследованию.
Зачем скажи мне это всё нужно, если все методы - виртуальные? И к тому же могут вызываться по переменной, содержащей название метода?
Для компилируемых языков это всё имеет некий смысл, для PHP что-то его не наблюдается.

Например я не знаю как с помощью пхп реализовать определение кол-ва народу на сайте в данный момент, на ява это делается просто.
Это достоинства наличия Java VM и возможности вставлять апплеты (и в целом идейной пропаганды Sun) а не языка программирования :)

Alexandre
А вот операцию "Выбрать всех пользователей, которые имеют в своей корзине товары" или там "Рейтинг предпочтнеий товаров в соответствии с региональным положение пользователей" ты в какой модуль запихнёшь? :)
Или - "удалить все товары, у которых не было покупателей в течение..."?
 

Screjet

Новичок
Originally posted by Alexandre
..т.е. при каждом действии отработки страницы используется три-четыре класса, например:
$page->init()
$page->edit()
$page->update()
$page->print()

соответственно
$page->delete()
$page->add()
отрабатывают при выполнении действий delete или add
Ну это по идее вызов методов. О каких классах идет речь?

И что это за принцип модульности странный?? Обычно, модуль = это класс (группа класов), который инклюдится в коде и создается некий объект этого класса. Например оплата: _только_ когда_ потребитель выполняет проплату, только в тот момент инклюдим файл с классом оплаты, создаем объект оплаты.
 

Alexandre

PHPПенсионер
ForJest
Это достоинства наличия Java VM и возможности вставлять апплеты (и в целом идейной пропаганды Sun) а не языка программирования
Это не достоинства наличия Java VM и аплетов, это возможности WEB-сервера в первую очередь. Аплеты тут вообще пе причем, реализация страниц осуществляется с помощью сервлетом.

"Выбрать всех пользователей, которые имеют в своей корзине товары" , "Рейтинг предпочтнеий товаров в соответствии с региональным положение пользователей" ,
Или - "удалить все товары, у которых не было покупателей в течение..."? ты в какой модуль запихнёшь?
это уже вариант стратегии построения сайта. Либо отдельный модуль, либо в модуль товары, пользователи, просто добавляется новый метод и все.
Наример: $users->CartFull()

Обычно, модуль = это класс (группа класов), который инклюдится в коде и создается некий объект этого класса. Например оплата: _только_ когда_ потребитель выполняет проплату, только в тот момент инклюдим файл с классом оплаты, создаем объект оплаты
Screjet По логике так и есть, оплата осуществляется в момент проплаты. Но если с "оплатой" как с объектом осущесвляем еще иные действия, то вызываем и в другой момет.
 

Screjet

Новичок
Originally posted by Alexandre
ScrejetНо если с "оплатой" как с объектом осущесвляем еще иные действия, то вызываем и в другой момет. [/B]
Например? Возврат денег? А интерфейс с мерчантом в этом же модуле? :)

(имхо) слабая объектная модель. Не определены четко объекты и что-чем занимается.
 

Orlis

Guest
С точки зрения продуктивности работы -- модуль это файл на 30-300 строк кода, независимо от языка, методологии и задачи.

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

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

Вместо $page->edit() часто достаточно Page::edit() или просто editPage()
 

Screjet

Новичок
Originally posted by Orlis

Лично я пришел к выводу, что создавать объекты сложных классов в веб-приложениях не имеет смысла.
1) Очевидно ты не сталкивался со сложными веб-приложениями :)
2) Сложных классов не должно быть. Иначе теряется смысл ООП.
 

Ямерт

The Old One
Чтобы идти к MVC, надо чётко разделять Контроллер (обработчик, диспетчер запроса), Модель (вся прочая логика), Вид (отображение информации). В том, что ты привёл, я не вижу никакого разделения на эти три составные вообще - только разбивку на модули. Как именно организовать MVC-подход, решать тебе, и никто здесь помочь не сможет. Главное, не пожалей времени на анализ и рисование классовой/модульной структуры.

З.Ы. Хотел тебе на всякий случай дать линк на свой доклад по использованию MVC в PHP, но там сейчас пусто пока. Если интересно, могу вечером по почте прислать - вдруг наткнёт тебя на какие-то нужные мысли.

-~{}~ 30.08.04 12:50:

Кстати, вот интересный проект есть, зацени: http://www.phpmvc.net/
 

Alexandre

PHPПенсионер
(имхо) слабая объектная модель. Не определены четко объекты и что-чем занимается.
объекты определяются в бизнес модели. Здесь дисскусия не о конкретной бизнес модели - а о построение системы в общем идеалогическом плане.
В каждом конкретном случае Интерфейс с мерчантом - дело сугубо индивидуальное. Если создается прототип магазина, который будет тиражироваться - это один подход.
Если одноразовый проект - то другой .

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