А в реальности требования 100500 раз меняются по ходу написания, а код и тесты пишет 1 человек. :)
Поэтому я предпочитаю писать параллельно (но не пишу, так как их никто не поддерживает, а часто и не вливает в мастер).
Боюсь, я на английском не осилю.
На бусурманском обычно льют воду ни о чем, говорят о тривиальных вещах, будто это какое-то открытие. :)
На выходных попробую. :)
П.С.
Постоянные читатели статьи.
Разве она со времени появления 2 года назад не улучшилась?
Я полностью с Вами согласен. :)
Просто иногда (часто) надобности в модели нет.
Сначала удобно набросать в контроллере. А потом по мере развития можно и вынести это в модель, когда будет понимание, что там должно быть.
Параметров для выбора много, но они (если брать популярные) похожи настолько, что переход с одного на другой просто не заметите.
Да потому что и фреймворк-то и не нужен. :)
Ведь где происходит основная возня с кодом?
В обработке данных проекта и их выводе.
Этой возней можно заниматься хоть на CMS, хоть на самописи. :)
Какие параметры еще есть, кроме популярности в регионе? :)
Возьмите symfony, там вы можете скомпоновать страницу из отдельных блоков, у каждого из которого будет свой контроллер (ну и общий контроллер для страницы). Выйдет вполне себе граф компонентов.
О, норм я не знал. :) Я же не буду проверять все фреймворки. В документации этот вопрос не освещался вроде ранее.
Ну, это то чего мне не хватало.
А до Вас за 2 года никто об этом не сказал.
(Сказали только, что можно ~полукостыльно, но это нежелательно якобы из-за дикого оверхеда).
Может это появилось недавно, после прочтения моей статьи? :)
явное всегда лучше неявного.
У меня тоже явно. В параметрах вызова «контроллера» указывается, какой шаблон выводить.
Просто код вызова шаблона программисту обычно не нужно вызывать.
Однако популярные фреймворки (например symfony) предоставляют из коробки декораторы над контроллерами которые сами экспоузнут результат работы контроллера в шаблон (аннотация Template).
То есть имеем одноразовые контроллеры, которые умеют рендерить только 1 шаблон?
А как же все рассказы об MVC? :)
Давайте тогда вернем register_globals.
в контексте рендринга шаблонов звучит это мягко скажем дико.
extract() делает примерно то же, что и register_globals :)
Вместо работы с массивов подсовывает переменные с именем, взятым из ключей массива.
то есть мы против register_globals но при этом любим суперглобальные переменные
А одно мешает другому? :)
Ибо просто глобальный стэйт вам ок.
А не всегда глобальное состояние это плохо.
Можно же обратиться к «состоянию» приложения?
В том же Yii 1.1 параметры так работают.
Ну и какой смысл не использовать GPCS, если под оберткой все равно работа с GPCS? :)
Я не говорю, что всегда лучше работать напрямую с GPCS. Иногда можно использовать свою обертку.
П.С.
А документация и продвижение фреймворков разве не расчитано на дебилов? :)
П.П.С.
Всем ораторам.
Читайте внимательно. Я никому не запрещаю пользоваться фреймворками!
Я лишь привожу свой опыт, что можно обойтись и без них.
П.П.П.С.
Кстати, статья дополнилась 2 пунктами недостатков в самом начале.
Суть примерно такая: Not invented here. :)
Но если вам пофиг на ООП, вместо request можно работать напрямую с $_GET и $_POST.
Это все детали.
Надо выбирать из этих $_GET и $_POST нужные данные и передавать их в модель/сервис/что-то-еще, что реализует бизнес-логику.
Бизнес-логику в контроллерах писать не надо.
Ну вот.
А это будет как бы и не бизнес логика.
Это как раз будет построение параметров для «модели».
А так как от модели никакая другая логика кроме выполнить запрос и отдать данные не требуются, то можно из контроллера вызвать нужный метод сущности и все. :)
П.С.
Статья чуток изменена касательно буквы М.
Код, касающийся модели можно размещать в контроллере, если он простой и нету дублирования.
Я просто не понимаю как на внутренний комп в корп сети может залезть зловред таким способом.
Только если ядро сети уже больное.
На MAC-адрес, на IP?
Иначе это следование тупым догмам. :)
Поэтому я предпочитаю писать параллельно (но не пишу, так как их никто не поддерживает, а часто и не вливает в мастер).
Это просто такая реализация, которая затьмила весь REST.
wiki
Вообще-то, GraphQL — подмножество REST.
На бусурманском обычно льют воду ни о чем, говорят о тривиальных вещах, будто это какое-то открытие. :)
На выходных попробую. :)
П.С.
Постоянные читатели статьи.
Разве она со времени появления 2 года назад не улучшилась?
А-ха-ха.
А разве не так? :)
О тестах
Это я пишу о личных проектах.
На работе по другому чуток. :)
Вы стремитесь к 100%-ому покрытию?
Просто иногда (часто) надобности в модели нет.
Сначала удобно набросать в контроллере. А потом по мере развития можно и вынести это в модель, когда будет понимание, что там должно быть.
Господи, если вы пишете проект на фреймворке — флаг вам в руки, хоть там сфе…
Ты тоже думаешь, что я пропагандирую писать запросы, как в комменте оратора ниже ( MetaDone )? :)
Может вам к психиатру? :)
Ищите комменты от «M-A-XG» в той теме. :)
А если проблем не было, то будут. :)
Да потому что и фреймворк-то и не нужен. :)
Ведь где происходит основная возня с кодом?
В обработке данных проекта и их выводе.
Этой возней можно заниматься хоть на CMS, хоть на самописи. :)
Какие параметры еще есть, кроме популярности в регионе? :)
О, норм я не знал. :) Я же не буду проверять все фреймворки. В документации этот вопрос не освещался вроде ранее.
Ну, это то чего мне не хватало.
А до Вас за 2 года никто об этом не сказал.
(Сказали только, что можно ~полукостыльно, но это нежелательно якобы из-за дикого оверхеда).
Может это появилось недавно, после прочтения моей статьи? :)
У меня тоже явно. В параметрах вызова «контроллера» указывается, какой шаблон выводить.
Просто код вызова шаблона программисту обычно не нужно вызывать.
То есть имеем одноразовые контроллеры, которые умеют рендерить только 1 шаблон?
А как же все рассказы об MVC? :)
extract() делает примерно то же, что и register_globals :)
Вместо работы с массивов подсовывает переменные с именем, взятым из ключей массива.
А одно мешает другому? :)
А не всегда глобальное состояние это плохо.
Можно же обратиться к «состоянию» приложения?
В том же Yii 1.1 параметры так работают.
Ну и какой смысл не использовать GPCS, если под оберткой все равно работа с GPCS? :)
Я не говорю, что всегда лучше работать напрямую с GPCS. Иногда можно использовать свою обертку.
П.С.
А документация и продвижение фреймворков разве не расчитано на дебилов? :)
П.П.С.
Всем ораторам.
Читайте внимательно. Я никому не запрещаю пользоваться фреймворками!
Я лишь привожу свой опыт, что можно обойтись и без них.
П.П.П.С.
Кстати, статья дополнилась 2 пунктами недостатков в самом начале.
Суть примерно такая: Not invented here. :)
Это все детали.
Ну вот.
А это будет как бы и не бизнес логика.
Это как раз будет построение параметров для «модели».
А так как от модели никакая другая логика кроме выполнить запрос и отдать данные не требуются, то можно из контроллера вызвать нужный метод сущности и все. :)
П.С.
Статья чуток изменена касательно буквы М.
Код, касающийся модели можно размещать в контроллере, если он простой и нету дублирования.