Я не знаю как назвать эту методологию, поэтому и назвал "сначала пишем вью, потом модель"… Принцип в том, что сначала пишется вью+контроллеры, далее все обращения к классам/методам/свойствам и глобальным функциям/переменным перехватываются средствами обработчиков библиотеки и складируется в базу.
Затем переходим в режим чтения перехваченных вызовов и реализуем функционал, параллельно анализируя необходимость реализации той или иной функциональности.
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → PHP для идиотов → Методология по разработке веб-приложений "сначала пишем вью, потом модель"
Методология по разработке веб-приложений "сначала пишем вью, потом модель"
Страницы: ← Следующая страница →
-
Сообщения:
22959
Репутация:
N
Группа:
в ухо
-
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:34, спустя 5 минут 36 секунд
[size=14]Пример[/size]
Нам надо реализовать вывод новостей
// Пишем вью/контроллер
$page = url::get('page'); // обработчик для $_GET['page']
$news = new news(); // несуществующий пока что класс "news"
echo 'Всего новостей: ' . $news->getCount();
echo 'Список новостей: ' . $news->getItems($page);
// и т.д.
А потом пишем модель
class news
{
…
}https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
11960
Репутация:
N
Группа:
в ухо
-
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:43, спустя 2 минуты 6 секунд
И… что вы думаете по этому поводу? Есть ли такие наработки, паттерны, методики существующие и т.д.?https://smappi.org/ - платформа по созданию API на все случаи жизни
-
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:49, спустя 5 минут 28 секунд
Дело в том, что обычно пишется модель, с излишним функционалом в принципе! Только с опытом конкретных решений (например соц. сеть, форум и т.д.) приходит четкий список функционала! Но по началу всегда пишешь лишнюю хрень, которая потом из проекта постепенно выходит, хотя и по началу она не нужна была. А то что надо реализовывать - не реализовывается…
Да, проектирование в принципе решило бы проблемы с излишним кодом в модели, думаю эта методология относится к XP (Extreme Programming)…https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:50, спустя 48 секунд
мне както привычно думать, что сначала рисуется болванка страницы. это практически вью. затем, если есть шаблонизатор, болванка размечается шаблонотегами под данные из контроллера и понеслась…
это вписывается в твою методологию?ιιlllιlllι унц-унц -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:52, спустя 2 минуты 38 секунд
Я и сейчас использую принцип "сначала пишем контроллеры и вью", а потом только "модель". Но я делаю конкретно для одного вью.
То есть, если не проектировать какой-либо модуль, то сначала я пишу его вью+контроллеры, а потом делаю модель, тем самым избегая лишних фантазий "что же надо сделать и что будет" в модели.
Я конкретно знаю на основании вью+контроллер что мне надо в модели.https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:54, спустя 1 минуту 50 секунд
artoodetoo, то есть при этом ты реализуешь функции после того как их используешь? То - да!https://smappi.org/ - платформа по созданию API на все случаи жизни
-
Сообщения:
2284
Репутация:
N
Группа:
Адекваты
14 мая 2009 г. 13:57, спустя 3 минуты 1 секунду
artoodetoo, ну раз данные вписываются из контроллера, то он уже готов, а следовательно это противоположность Эдвордовской методологии.
adw0rd, вообще очень интересная идея, сам пока чего-то всегда пишу функционал (назвать их контроллерами нельзя - не тот у меня уровень, чтоб писать отдельно все и при этом грамотно), а потом уже вьюшку. При этом несколько раз переписываются значительные куски функционала, дабы подстроится под вьюшку. В общем, создаю сам себе лишнюю работу.
Но в целом насчет проектирования - самый лучший вариант. Пишешь что нужно, как нужно, и, главное, нахрена оно нужно, после этого все будет намного проще :) -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 13:59, спустя 1 минуту 47 секунд
Может назвать "Сначала пользуемся, потом делаем"?https://smappi.org/ - платформа по созданию API на все случаи жизни
-
Сообщения:
440
Репутация:
N
Группа:
Адекваты
14 мая 2009 г. 14:03, спустя 3 минуты 56 секунд
чем то интерфейсы напоминает… В принципе это и есть суть ООП… Пишем "сверху вниз". Абстрактно что хотим увидеть а потом реализовываем. Я так пишу в 9 из 10 случаях… Удобно -
Сообщения:
5147
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 14:04, спустя 57 секунд
про "чтение перехваченных вызовов" можно поподробнее?ιιlllιlllι унц-унц
-
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 14:04, спустя 22 секунды
Givi, ну контроллер я пишу вместе с вью, то есть иду по логике программы. Только вот модель потом реализую.
То есть:
// Контроллер сразу реализую
if (isset($_GET['x']))
// Обращение к контроллер (потом напишу его содержимое, если еще не написал)
if (!$user->isLevel(9)) return;
// Обращение к модели (потом напишу ее содержимое)
foreach($news->getItems() as $V) {
// echo …
}
Получается какие-то контроллеры юзаются сразу, какие-то дописываются, но как правило контроллеры бывают общими, а модели нет.https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
22959
Репутация:
N
Группа:
в ухо
14 мая 2009 г. 14:06, спустя 1 минуту 56 секунд
про "чтение перехваченных вызовов" можно поподробнее?
Подключается свой-фреймворк с __autoload+__get/__set/__call. Но это только идеи, можно еще как-то, пока не думал и естественно нет готового решения… Поэтому и предлагаю подумать.https://smappi.org/ - платформа по созданию API на все случаи жизни -
Сообщения:
2284
Репутация:
N
Группа:
Адекваты
14 мая 2009 г. 14:28, спустя 21 минуту 37 секунд
adw0rd, у меня просто как такового контроллера нет (он у меня по большей мере был совмещен с моделью, и кусочками в вьювере был). Точнее я раньше такого не делал. Сейчас же, после разбора и небольшого ковыряния в КодИгнитере понял куда нужно направляться. Осталось только правильно проектировать. Хотя, для мелких проектов это (серьезное проектирование) не самое главное, как по мне.
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!