контролеры давно придуманы как таковые, а вот использование в PHP их я думаю начал с первыми. я же написал что изобрел колесо — эта методика была давно известна, просто у нас о ней мало пишут.
в контексте PHP, сейчас я работаю в проекте с ZF, также приходилось использовать CakePHP, про java — NetBeens предлагает огромнейший выбьор всего, за приделы редко вылетал.
функциональное: когда блок «а» делает работу типа «а», блок «б» делает работу типа «б».
распределение по данным: есть поток данных и все блоки его колят, как-то синхронизируясь.
повторюсь и я… затраты на поиск/изучение готового решения часто сопоставимы с написанием своего, и еще я не против фрейморков как таковых, я против того, чтоб отказываться от велосипедов.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
Как я уже написал выше, я сам иду по другому пути — наследую компоненты фреймворка и добавляю в них ту функциональность, которой лично мне нехватает
впринципе я не против такой позиции, просто у меня другая. Ну не находил я фраймов которые имеют привлекательные мне слои абстракции, а ведь с этого все начинается.
Я понял вас, понял ваши аргументы, но они мне кажутся недостаточно значительны чтобы избрать фреймворк и присоединиться к таким людям, да я изучаю фреймворки, но не сажаю на них свои большие проекты.
я предпочитаю библиотеки: инструменты которые отлажено решают узкий класс задач, которые избавлены от необходимости жить в особой среде фреймворка — это мой выбор, а то ваш, у нас нет точек конфронтации.
затраты на введение фраймворка сопоставимы с затратами на работу без него — это основная проблемма.
язык PHP мы выбирали именно основываясь на анализе и потребности.
в целом попробуйте посмотреть по другому:
вам нужен компонент вашей системы, он нужен для чего-то.
у вас 2 равноварианта: поиск решения (поиск готового кода) и поиск решения (написание кода), как видите они часто равнозначны.
Если человек не может написать шаблонизатор который будет удовлетворять его потребности в 70% случаев, то он не сможет и смарти толково использовать.
Начинать нужно Всегда с анализа того, что есть, именно поэтому изучение фраймворка полезная работа, что-то да останется, если вы ничего не подчерпнули, не взяли, не оставили себе — то вы не изучили фраймворк. Но говорить, что фраймворк должен доминировать над собственными разработками в продакшене — это ИМХО не верно. Я считаю, что свои разработки очень полезны, как с точки зрения развития так и с точки зрения бизнеса. Своя разработка предсказуема и управляема, всегда есть ответственное лицо которое может внести изменения. Если вы добиваетесь такойже управляемости с фраймворком, то используйте его! в моих командах я ниразу не пропускал использование фрайма, который бы был досконально изучен и считаю, что делал верно.
пример:
В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями.
в принципе очень клевая штуковина, давайте попробуем ее использовать.
Допустим роль определяется в результате какой либо инициализации при старте системы. определили что наш пользователь есть «moderator» унаследованный от «user» который в свою очередь унаследован от «guest».
все сделать просто, все работает, но система дорабатывается… допустим что в результате дальнейшей инициализации системы было обнаружено что наш пользователь заблокирован (класс «block»), тоесть ему запрещен доступ к каким-то ресурсам. пробуем реализовать это на Zend_Acl и… тупик — это как раз пример когда мы вышли за контекст использования Zend_Acl. эту задачу решить в рамках Acl можно, но не нужно ибо решение будет некрасивым и будет нарушен слой абстракций (нам придется выносить логику управления ресурсами за приделы Acl)
Конфликт произошел по причине наследования от нескольких ролей.
Zend_Acl решает эту неоднозначность, завершая запрос, как только находит первое правило, которое может быть применено к запросу.
пример несколько грамоздкий, но наглядный.
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
Вы правильно написали, что «Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.» если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!
про худение это особый момент. Дело в том, что часто часть написанная на фреймворке занимает 70%-95% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
ну тогда вы можете совершить очередной раз извечную ошибку разработчиков:
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
согласен, в целом изучение фраймворка — это удивительно полезная деятельность. половина моего поста имено и посвящена вопросу что фраймворк нада изучить. Как правило так и получается что нарвится почти все, и поэтому идеи и патрены понравившегося фраймворка переплывают в свою разработку. Но опять же если вы ищите решение, то нада использовать либу, ее, например, и из фраймворка можно выдрать.
распределение по данным: есть поток данных и все блоки его колят, как-то синхронизируясь.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
впринципе я не против такой позиции, просто у меня другая. Ну не находил я фраймов которые имеют привлекательные мне слои абстракции, а ведь с этого все начинается.
Я понял вас, понял ваши аргументы, но они мне кажутся недостаточно значительны чтобы избрать фреймворк и присоединиться к таким людям, да я изучаю фреймворки, но не сажаю на них свои большие проекты.
я предпочитаю библиотеки: инструменты которые отлажено решают узкий класс задач, которые избавлены от необходимости жить в особой среде фреймворка — это мой выбор, а то ваш, у нас нет точек конфронтации.
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
язык PHP мы выбирали именно основываясь на анализе и потребности.
в целом попробуйте посмотреть по другому:
вам нужен компонент вашей системы, он нужен для чего-то.
у вас 2 равноварианта: поиск решения (поиск готового кода) и поиск решения (написание кода), как видите они часто равнозначны.
Если человек не может написать шаблонизатор который будет удовлетворять его потребности в 70% случаев, то он не сможет и смарти толково использовать.
Начинать нужно Всегда с анализа того, что есть, именно поэтому изучение фраймворка полезная работа, что-то да останется, если вы ничего не подчерпнули, не взяли, не оставили себе — то вы не изучили фраймворк. Но говорить, что фраймворк должен доминировать над собственными разработками в продакшене — это ИМХО не верно. Я считаю, что свои разработки очень полезны, как с точки зрения развития так и с точки зрения бизнеса. Своя разработка предсказуема и управляема, всегда есть ответственное лицо которое может внести изменения. Если вы добиваетесь такойже управляемости с фраймворком, то используйте его! в моих командах я ниразу не пропускал использование фрайма, который бы был досконально изучен и считаю, что делал верно.
пример:
В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями.
в принципе очень клевая штуковина, давайте попробуем ее использовать.
Допустим роль определяется в результате какой либо инициализации при старте системы. определили что наш пользователь есть «moderator» унаследованный от «user» который в свою очередь унаследован от «guest».
все сделать просто, все работает, но система дорабатывается… допустим что в результате дальнейшей инициализации системы было обнаружено что наш пользователь заблокирован (класс «block»), тоесть ему запрещен доступ к каким-то ресурсам. пробуем реализовать это на Zend_Acl и… тупик — это как раз пример когда мы вышли за контекст использования Zend_Acl. эту задачу решить в рамках Acl можно, но не нужно ибо решение будет некрасивым и будет нарушен слой абстракций (нам придется выносить логику управления ресурсами за приделы Acl)
прошу прощения у тех, кто не работал с Zend_Acl прочитать кратко можно framework.zend.com/manual/ru/zend.acl.html, проблема кроется в том, что
Конфликт произошел по причине наследования от нескольких ролей.
Zend_Acl решает эту неоднозначность, завершая запрос, как только находит первое правило, которое может быть применено к запросу.
пример несколько грамоздкий, но наглядный.
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
Вы правильно написали, что «Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.» если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!
про худение это особый момент. Дело в том, что часто часть написанная на фреймворке занимает 70%-95% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
я посчитал что эта вещь включает ту, о которой вы сказали.