организация контролера web приложения mvc

texrdcom

Новичок
организация контролера web приложения mvc

Как лутче обустроить контролер в приложении ?
Есть урл http://localhost/forum/showmessage/
В данный момент сделанна так
есть контролер Forum.php это класс
PHP:
class Forum 
{
   // Имеет метод
   public function showmessage()
  {
   // если параметров нет просто выводит сообщения 
  // все которые доступны для форума 
 // темы сообщений + постраниный вывод данной инфы
  } 
}
Также допустим урл в системе
http://localhost/forum/showmessage/id/1234/
В контролера получаем параметер автоматом
$array['id'] = 1234; // Это свойство контролера не глобальная переменная
Формат id проверяеться автоматом там может быть только [a-z0-9-_]
Вот возникает вопрос кто должен учитывать наличия данного параметра в запросе
Контролер->showmessage()

Или все параметры должны передваться в
модель $model->showmessage($ALLPARAMS) ?
а модель сама решит какие данные вернуть ? вернее не данные а
достанет данные относительно наличия + правильности параметров
(Ведь могут задать id сообщения которого уже нет в системе его удалили!)
плюс подключит в зависимости от параметров шаблон вида
и вернет результат работы в виде строки - Готового html в котором будут отображенны
данные.


Вопрос два как лутче обустроить контролер
- это единный файл
- или для каждого метода типа showmessage создаеться отдельный файл
- с базовой функцией start() - грубо говоря.

Хотелось бы услышать ваше мнение.
 

bkonst

.. хочется странного?...
Лично мое мнение (сложившееся на основании знакомства с Ruby-on-Rails и собственного опыта) - валидация и прочая предварительная обработка параметров, переданных пользователем - это задача контроллера. Модель содержит только методы с "нормальными" сигнатурами, которые легко запомнить и использовать.
 

voituk

прозревший
отвечу на второй вопрос:
В данном случае лучше всего в один вфайл.

А в общем случае не заморачивайся с файловой организацией. Чаще всего понимание того как правильно спроецировать сущности системы на файлы приходит позже. Тогда берешь в руки любимый refactoring tool и начинаешь организовывать "как удобнее".
 

bkonst

.. хочется странного?...
voituk
Разве для PHP есть приличные IDE, поддерживающие автоматический рефакторинг?
 

texrdcom

Новичок
voituk
refactoring tool - Скажи ты какой изпользуеш ?


не заморачивайся с файловой организацией
Как не заморачиваться ? потом переписывать все ? или лутче
продумать на перед ?

Да один файл в данном случаи а если будет урл /admin/ - контролер админ интефрейса может
иметь не одну и не две функции а несколько десятков ...

Хочеться просто организвать структуру одно типно !

-~{}~ 20.09.06 12:45:

bkonst
Скажи как в rails организован котролер ? это один файл
с кучей методов или как ? или вообще нет такого понятия как файл контролера ?
 

voituk

прозревший
А чем вам grep+sed+vim не refactoring tools?
Тут уже на вкус и цвет, как говорится...

Я использую JEdit + несколько самописных макросов к нему - и достаточно для поведения рефакторинга средней сложности.

Рефакторинги высокой сложности стараюсь не применять.

-~{}~ 20.09.06 12:17:

CodeIgniter http://www.codeigniter.com
тоже все в одном файле держит.
 

bkonst

.. хочется странного?...
Тем, что grep+sed+vim ничего не знают ни о синтаксисе PHP(*), ни о ООП. Понятно, что с помощью search, replace, прямых рук, лома и такой-то матери можно сделать очень многое. Однако ж, хочется комфорта и спокойствия.

(*) по большому счету.
 

voituk

прозревший
bkonst
Предложи вариант лучше!
Меня, конечно, куда больше впечатляют средства рефакторинга для Java в Eclipse, но пока довольствуемся тем, что есть.

P.S. Для JEdit есть плугин PHPParser, какой знает и про ООП и про синтаксис php. При желании можно написать пару макросов какие его используют.
 

bkonst

.. хочется странного?...
Предложи вариант лучше!
Меня, конечно, куда больше впечатляют средства рефакторинга для Java в Eclipse, но пока довольствуемся тем, что есть.
Вот я ж и грущу... что приходится есть то, что есть.
 
Часто бывает удобно организовывать действия, как отдельные классы (Command), а не методы класса. См. паттерн Front Controller Фаулера.
 

<-svazist->

Новичок
Может не стоит городить огород, а использовать имеющиеся разработки?
Если говорить про архитектуру приложения, то классическая схема MVC Model2 не плохо справлятся со своими обязанностями.

Уровни и роли в модели MVC:

Контроллер:

1. Приложение
- работа с модулями
- глобальные параметры

2. Модуль
- работа с коммандами
- валидация данных
- форварды ( логика передачи управления уровню презентации )

3. Комманда
- работа с сущностями
- принятие решения о следующем шаге

4. Презентация
- Иннициализация представление и передача параметров

Представление:

Генерация XHTML/XML/JSON/PLAIN_TEXT/....
Используем Smarty/XSLT/echo/....


Модель:
Классы сущностей, Фабрики, DAO, классы абстракции БД

По размещению файлов: Идеология 1 класс - 1 файл - самое оно. И структуру каталогов выбрать типа:

"Forum/Actions/ShowMessageAction.php" - класс комманды ShowMessage - модуля Forum (Требуется вывести сообщение по ID)

"Forum/Actions/ShowMessageListAction.php" - класс комманды ShowMessageList - модуля Forum (Требуется вывести список сообщений для ID треда )

"Forum/Model/Message.php" - класс сообщения (Bean - просто обвётка на некую структуру данных ID/Тред/Автор/Дата/Заголовок/ТекстСообщения )

"Forum/Model/MessageDAO.php" - класс работы с сообщениями (получение сообщения по ID/сохранение сообщения/удаление сообщения по ID - методы класса MessageDAO)

"Forum/Presentation/XML.php" - класс вывода в XML
"Forum/Presentation/Main.php" - класс вывода в HTML

"Forum/templates/message.tpl" - Smarty шаблон для вывода сообщения
"Forum/templates/messageList.tpl" - Smarty шаблон для вывода списка сообщений
"Forum/templates/messageList.xsl" - XSLT шаблон для вывода списка сообщений

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

По данной теме много информации, в основном "на языке оригинала"

хороший вводный курс

http://struts.apache.org/1.x/userGuide/introduction.html#history

а так же в google.com
 

Alexandre

PHPПенсионер
если отталкиваться от идеалогии Java M2, то я бы тогда рекомендовал использовать идеалогию пакетов.
Пакет в применении пхп - это файл, содержащий в себе несколько однотипных классов.

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

Работать (Рефакторить) с одним средним файлом проще, сем с кучей мелких файлов (особенно когда работаешь по фтп).

Хочется отметить, что строить архитектуру пакетов - это такое же ис-во, как и строить архитектуру классов.
 

demongloom

Новичок
А может кто то написать или привести ссылку на наиболее простейший пример MVC в коде? Хочу познать эту технологию, но вот примеры как один сложноватые.
 
Сверху