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

[Screamer]

видно мое решение больше подходит под определение "Контроллер страниц" а твое под "Контроллер запросов"

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

 

[BeGe]

Для изобретателей велосипедов - обратите внимание на проект Apache Cocoon http://cocoon.apache.org

 

[Alexandre]

Для изобретателей велосипедов ...

Какой русский не любит руссой езды,
да еще и на собственноручно собранном велосипеде.

есть так же проекты Apache Strats и phpmvc
все мы винтики эти изучали, в них есть свои плюсы и минусы.

Правильно ли будет иметь в системе оба уровня контроллеров - сначала отрабатывает контроллер страницы, который потом передает управление одному из контроллеров моделей?

Screamer согласен, есть решения и комбинированного типа.

У меня решение следуещее:
есть Один универсальный Контроллер, который распознает Модель и передает ей все данные.

Модель представляет собой класс, наследник от AbstractModel, который абдейтит данные в БД (если нужно) и вызывает необходимый класс Представление (или несколько классов Представление).

Класс Представление, выводит данные из БД и вызывает соответствующий шаблон для представления Данных.
Выходной HTML код записывается в стек (или массив)

Далее все шаблоны собираются Одним Супершаблоном и выходной HTML код выдается в выходной поток.

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

 

[Screjet]

есть Один универсальный Контроллер, который распознает Модель и передает ей все данные.

Думал над этим.. Даже в какихто CMSках наблюдал. Отказался.
"Универсальности" все равно не удалось добиться. У каждого контролера свои заморочки (в зависимости от предметной области).

У меня: главный = контролер предметной области, а остальные элементы = компоненты. И супершаблон = тоже всегото подчиненный компонент.

 

[chameleon]

Для изобретателей велосипедов - обратите внимание на проект Apache Cocoon http://cocoon.apache.org

да я говорил уже ...но товарищей, что называется, понесло... ..

 

[Screjet]

Любителей продавать ворованные велосипеды просьба не беспокоить

 

[_RVK_]

Раз уж тут употребили слово "компонент", то предлагаю обратить внимание на объектную модель Delphi. Это же сплошное MVC! По аналогии можно разработать модель и для web. Сори за оффтоп....

 

[wizardz]

Автор оригинала: Diesel
Раз уж тут употребили слово "компонент", то предлогаю обратить внимание на объектную модель Delphi. Это же сплошное MVC! По аналогии можно разработать модель и для web.

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

PRADO PHP component framework

 

[Alexandre]

Раз уж тут употребили слово "компонент", то предлагаю обратить внимание на объектную модель Delphi.

В этом плане нас уже опередил Microsoft со своим продуктом NET.Studio
здесь его нам уже не догнать.

 

[_RVK_]

Да, это как раз тот случай когда разработчики попытались объять необъятное и впихнуть невпихуемое...
Я имел ввиду взять только объектную модель а не реализовать объекно - событийное программирование на PHP... Хотя идея в PRADO всеже интересная. Есть что печерпнуть...

-~{}~ 08.10.04 11:28:

здесь его нам уже не догнать

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

 

[Alexandre]

Хотя идея в PRADO всеже интересная. Есть что печерпнуть...

а что именно, мне эта модель например не нравится, но это отдельный флейм, я наверно эту тему затрону чуть позже, хочу сделать сравнение технологий .NET и PHP

-~{}~ 08.10.04 12:03:

Как я понимаю цель разработать обектную модель приложения на пхп, которая соответствует патерну MVC

ОК,

Я не предлагаю взять модель и тупо её скопировать. Я предлогаю посмотреть, и почерпнуть идею модели.

ОК

 

[_RVK_]

а что именно

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

 

[Alexandre]

Отсюда можно взять идею файлов инициализации для объектов приложени

только эту идею во всю и использую

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

не хотелось бы обсуждать +/- .NET - надо заводить новый топик. Но у меня тоже есть мнения по этому поводу.

 

[Макс]

Хмм, вы считаете событийную логику приемлемой для web ?
Флеймить по этому поводу не собираюсь, просто интересно мнение со стороны.

PS
prado недавно смотрел. Двоякое впечатление. С одной стороны, один из наиболее качественных framework-ов которые мне удалось увидеть. С другой стороны я противник событийной логики в web.

 

[_RVK_]

Макс
Событийная логика это нечто большее. Здесь же всего лишь сам факт нажатия на кнопку. Можно самому напрямую проверять параметр из GET/POST, а можно поручить это объекту, и больше не беспокоится. Указал в файле инициализации что нажатие на эту кнопку обрабатывает эта функция/метод и работаешь только с ней. Удобно.

 

[Screjet]

Prado можно брать за образец:
У шаблона есть обратная связь.

 

[_RVK_]

2all

Возник такой вопрос....

Кто в MVC должен заниматься обработкой ошибок?

Например газета. Есть класс модели newspaper, который занимается созданием номеров, добавлением к номеру статей, новостей и т.д. У него есть соответствующие методы: new_relase, add_article, add_news и т.д.

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

Как правильнее по вашему?

 

[Alexandre]

я выскажу только, как реализованно (почти реализованно) у меня (потому-что, как сказал Энштейн - все в мире относительно).

Контроллер воспринимает все запросы.
По запросу он онализирует - какой класс (Модели) - > метод надо вызвать.

Модель ( класс производный от BaseModel) имеет обработчик ошибок

При том, в базовом классе BaseModel - заложены базовые методы на проверку ошибок.

Заложены следующие Типы проверок:
- число
- дата
- строка
- маил
- урл
- рег.выражение

проверка (вызов метода) $baseModel->test( array $in, array $varName ) возвращает bool массив соответствия: прошла/не прошла переменная проверку.

анализируется $errArr и формируется код возврата Модели.

Далее в зависимости от кода возврата вызывается класс Представление.

Если код возврата > 0 то в зависимости от алгоритмя анализируется $errArr и вызывается соответствующий шаблон.

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

-~{}~ 17.11.04 11:00:

Макс

Хмм, вы считаете событийную логику приемлемой для web ?
Флеймить по этому поводу не собираюсь, просто интересно мнение со стороны.

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

все обрабатываю сам.

Придерживаюсь правила (может оно не правильное) - один законченный функциональный модуль - одна WEB страница.

В соответствии с концепцией дотнет - одна форма - одна WEB страница.

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

по этому - вся событийная логика - в корзину

 

[netklon]

Проверка заложена в отдельных классах ValidEmail, ValidString, ValidDate и т.д. Есть фабрика для создания объектов этих классов Validator.
$valid_string = Validator::create("String", $string);
$valid_string->checkLength(5, 20);
Собственно фабрику можно сделать свойством класса BaseModel, можно реализовать ее на паттерне "Одиночка" или просто создавать как внутреннюю переменную метода класса при необходимости.

 

[_RVK_]

Собственно класс PEAR так же содержит средства обработки ошибок....

Почему возникли сомнения? Для обработки ошибок пользуюсь своим классом log который умеет:
1. Просто вывести сообщение.
2. Записать в лог и вывести сообщение.
3. Переправить на другую страницу, и вывести сообщение.

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

Сначала я делал так. В классе модели были определены константы ошибок, например ERR_VAR_EMPTY, ERR_VALID_EMAIL...
Методы сами осуществляли проверку и возвращали значение соответствующей константы. В контроллере я сравнивал возвращаемое значение с соответствующей константой, и выводил сообщение (точнее передавал масив сообщений во View). Но сейчас почему-то посчитал что удобнее проводить проверку до передачи данных модели, а сама модель контролирует только работу с БД.

Alexandre Ну не поеду же я к тебе в питер с пивом, чтоб ты подробнее объяснил

возвращает bool массив соответствия: прошла/не прошла переменная проверку

анализируется $errArr и формируется код возврата Модели

Далее в зависимости от кода возврата вызывается класс Представление

Вот это можно подробнее?