затраты на введение фраймворка сопоставимы с затратами на работу без него — это основная проблемма.
язык PHP мы выбирали именно основываясь на анализе и потребности.
в целом попробуйте посмотреть по другому:
вам нужен компонент вашей системы, он нужен для чего-то.
у вас 2 равноварианта: поиск решения (поиск готового кода) и поиск решения (написание кода), как видите они часто равнозначны.
Если человек не может написать шаблонизатор который будет удовлетворять его потребности в 70% случаев, то он не сможет и смарти толково использовать.
Начинать нужно Всегда с анализа того, что есть, именно поэтому изучение фраймворка полезная работа, что-то да останется, если вы ничего не подчерпнули, не взяли, не оставили себе — то вы не изучили фраймворк. Но говорить, что фраймворк должен доминировать над собственными разработками в продакшене — это ИМХО не верно. Я считаю, что свои разработки очень полезны, как с точки зрения развития так и с точки зрения бизнеса. Своя разработка предсказуема и управляема, всегда есть ответственное лицо которое может внести изменения. Если вы добиваетесь такойже управляемости с фраймворком, то используйте его! в моих командах я ниразу не пропускал использование фрайма, который бы был досконально изучен и считаю, что делал верно.
пример:
В Zend_Acl роль может наследоваться от одной или от нескольких ролей. Это реализовано для поддержки наследования правил между ролями.
в принципе очень клевая штуковина, давайте попробуем ее использовать.
Допустим роль определяется в результате какой либо инициализации при старте системы. определили что наш пользователь есть «moderator» унаследованный от «user» который в свою очередь унаследован от «guest».
все сделать просто, все работает, но система дорабатывается… допустим что в результате дальнейшей инициализации системы было обнаружено что наш пользователь заблокирован (класс «block»), тоесть ему запрещен доступ к каким-то ресурсам. пробуем реализовать это на Zend_Acl и… тупик — это как раз пример когда мы вышли за контекст использования Zend_Acl. эту задачу решить в рамках Acl можно, но не нужно ибо решение будет некрасивым и будет нарушен слой абстракций (нам придется выносить логику управления ресурсами за приделы Acl)
Конфликт произошел по причине наследования от нескольких ролей.
Zend_Acl решает эту неоднозначность, завершая запрос, как только находит первое правило, которое может быть применено к запросу.
пример несколько грамоздкий, но наглядный.
Автор фреймворка работает обычно в другом контексте чем вы, поэтому то какую решает проблему он и которую решаете вы часто различны.
Вы правильно написали, что «Во фреймворках с правильной модульной архитектурой компоненты можно использовать как все вместе, так и по отдельности.» если из фреймворка можно вырвать интересующий вас кусок, то вам повезло =), делайте это!
про худение это особый момент. Дело в том, что часто часть написанная на фреймворке занимает 70%-95% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
ну тогда вы можете совершить очередной раз извечную ошибку разработчиков:
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
согласен, в целом изучение фраймворка — это удивительно полезная деятельность. половина моего поста имено и посвящена вопросу что фраймворк нада изучить. Как правило так и получается что нарвится почти все, и поэтому идеи и патрены понравившегося фраймворка переплывают в свою разработку. Но опять же если вы ищите решение, то нада использовать либу, ее, например, и из фраймворка можно выдрать.
хм… я тим лидер команды проекта incomeproject.com (это большая площадка для создания партнерских программ), могу сказать, что использование сторонних библиотек осложнено как минимум по таким причинам:
чтобы использовать такую библиотеку в серьезном проекте ей нужно полностью доверять, чтобы ей доверять ее надо изучить и обкатать на каком-либо «не важном» проекте, таких обычно нет.
нужно полностью понимать область применения, условия работы Фреймворка, методологию решения проблем, которую он предлагает. если этого нет, то вы рано или поздно встанете в ситуацию когда Фреймворк не удовлетворяет ваших требований и нужно писать «костыль» тут то вы и попадете в ловушку когда нужно ставить еще и еще костыли. поставить костыль корректно (под нужным углом) и не нарушить логической целостности работы приложения основанной на FW вы все равно можете только в случае если понимаете идеологию решения задачи, которая заложена в Фреймворк.
Таким образом что б начать пользовать Фреймворк вам нужно:
попробовать его где либо в слабо значительном месте.
изучить всю доку и знать типичные примеры, желательно потусовать в сообществах и узнать типичные проблемы
понять идеалогию решения (большой Фреймворк, много авторов, а значит много разношерстных решений)
осознать ВСЕ уровни абстракций используемых в Фреймворке.
написать где-то долго играющий, но опять же критичный проект на этом Фреймворке.
вот, только теперь можно использовать данный Фреймворк в своих проектах…
все что я тут написал — это мое мнение, моя позиция, но она основана на опыте человека, который написал системы на PHP (ну и не только php), работающие на свыше 5-ти машинах как с функциональным распределением вычислений, так и с распределением вычислений по данным и прекрасно масштабируемы.
доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
почему я использую свои разработки и предпочитаю изучать патерны, а не Фреймворки?
знание паттернов программирования дает вам не само блюдо, а рецепт как приготовить блюдо, вы вольны использовать любые поваренные приборы: PHP JAVA С++.
вы сможете добавить специи по своему выбору, если вы работаете в команде, то у вас больше шанцев изменить рецепт до приготовления, так чтоб ни у кого из членов команды не было аллергии на отдельные его части.
вы можете использовать сезонные и свежие овощи! например, если только что появилась возможность использовать наймспайсы, вы их любите, то вы уже можете включить их в состав своих блюд! я очень сомневаюсь, что шеф повар вашего любимого Фреймворка обладает достаточной гибкостью чтоб сделать это.
худеем — нужно меньше калорий… я думаю, что вам не зачем тащить с собой всю инфраструктуру Фреймворков просто, чтоб оно работало «как всегда» или на «всякий случай», вы же готовите!, а значит, на столе не должно быть ничего лишнего.
«используйте только соевый соус» — подумайте должны ли вы так строго соблюдать рецепт?? а что если вам хочется кетчуп? отказаться от таматов? ограничения вызванные использованием готового фраймворка иногда оказываются очень серьезными и вам не нужными.
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды минусы:
нет сообщества, которое обсудит ВАШУ проблемму
велика вероятность «глупых» ошибок
вы варитесь в собственном соку — не знаете новых методов если всегда все делаете сами
Сложно предать проект другим людям
Плюсы:
вы имеете полную свободу выбора, все что вы делаете вы можете сделать как вам угодно
в любом месте вы можете вставить новое решение и будете знать как это изменит вашу систему
вы можете решить любую проблему! вы автор системы, вам подвластны решения
все органичения вам подвластны
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)
ну занятная штука. интересно было посмотреть, интересный метод, использовать не собираюсь, но автору метода респект, задача так сказать с точки зрения самой задачи весьма занятная и интересно решена.
а я считаю, что статья крайне полезная, нужно знать как это делается и уметь читать, не вижу что б автор заставлял вас использовать эти методы, не хотите не используйте, но знать о их существовании вы обязанны если хотите считать себя хорошим хотябы кодером.
для тех кто не считает использование логических операторов для управления потоком управления дурным тоном напомню, что этот пример является класическим и вторая запись общепризнана (не вами, а классиками-фундаменталистами) более читаемой.
$res = mysql_connect(…);
if (!$res) die();
Аналогично:
$res = mysql_connect(…) or die();
выбор как и что использовать, конечно, остается на совести программиста
простите у вас тут дискуссия длинная.. затяжная. я даже прочел. у меня даже вопросы появились, но я решил их не задавать. Возможно немного эгоистично, но выскажу просто мнение свое:
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
Имхо идея не плохая, даже хорошая, но есть трудности которые нужно решить чтоб этот подход позволил накапливать опыт в библиотеках:
1. сложность наследования сервисов таких, разделение прав и прочего. не представляю как осуществлять наследуемость в таких структурах
2. как было сказано выше прохая инкапсулируемость.
Переводчику респект, особый респект за то что все сделано одним куском - очень удобно найти ответ на возникший глюк. Блин отличный труд. я очень благодарен
помоему это очень хороший и удобный сервис для маленьких и тестовых проектов.
вот я, например, пришел другу страничку править хочу там какой-то эффект MooTools так я ж не должен теперь качать,ставить я просто могу ему написать эффект и показать "вот мол смотри, нравится или нет".
конечно для продакшион проджектов такое использовать не рекоменуется.
вот у меня сразу вопрос.. они конечно сосут статистику, можно даже посмотреть какую, а вот влияет ли это как-то на TRUST сайта, задержку перед началом индексирования нового сайта, продвижение его в песочнице? думаю что нужно поставить эксперимент. вопросов много.. насколько этот сервис интегрирован с другими. наверняка обратная связь есть, только как она работает?
язык 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% работы скрипта и как оптимизировать ее не ясно, хотя задача не кажется иногда такой большой, поэтому приходится думать о том как «худеть».
а в целом за ответ спасибо, я не тотальный противник фреймворков, я противник их неосознаного выбора.
решать нада конкретную задачу а не абстрактную и потому нада иметь набор интсрументов, а не мотнстра который умеет все за вас.
я посчитал что эта вещь включает ту, о которой вы сказали.
чтобы использовать такую библиотеку в серьезном проекте ей нужно полностью доверять, чтобы ей доверять ее надо изучить и обкатать на каком-либо «не важном» проекте, таких обычно нет.
нужно полностью понимать область применения, условия работы Фреймворка, методологию решения проблем, которую он предлагает. если этого нет, то вы рано или поздно встанете в ситуацию когда Фреймворк не удовлетворяет ваших требований и нужно писать «костыль» тут то вы и попадете в ловушку когда нужно ставить еще и еще костыли. поставить костыль корректно (под нужным углом) и не нарушить логической целостности работы приложения основанной на FW вы все равно можете только в случае если понимаете идеологию решения задачи, которая заложена в Фреймворк.
Таким образом что б начать пользовать Фреймворк вам нужно:
вот, только теперь можно использовать данный Фреймворк в своих проектах…
все что я тут написал — это мое мнение, моя позиция, но она основана на опыте человека, который написал системы на PHP (ну и не только php), работающие на свыше 5-ти машинах как с функциональным распределением вычислений, так и с распределением вычислений по данным и прекрасно масштабируемы.
доверие к С++, С и Java обусловлено вовсе не одним фактом бренда, который за ними стоит, хотя и им тоже, но еще и старостью технологии Java`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
почему я использую свои разработки и предпочитаю изучать патерны, а не Фреймворки?
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды
минусы:
Плюсы:
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)
для тех кто не считает использование логических операторов для управления потоком управления дурным тоном напомню, что этот пример является класическим и вторая запись общепризнана (не вами, а классиками-фундаменталистами) более читаемой.
$res = mysql_connect(…);
if (!$res) die();
Аналогично:
$res = mysql_connect(…) or die();
выбор как и что использовать, конечно, остается на совести программиста
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
1. сложность наследования сервисов таких, разделение прав и прочего. не представляю как осуществлять наследуемость в таких структурах
2. как было сказано выше прохая инкапсулируемость.
$functions=json_decode($_REQUEST['method'],TRUE);
$UImethod->run($functions);
echo json_encode($UImethod->result);
мне кажется в этих строках сложно сделать прозрачным ограничение на разрешенные и запрешенные методы класса..
а в целом для маленьких задачь с маленьким кол-вом функций очень даже удобно. коротко и вызовы прозрачные впринципе
Может стоит просто сделать нечно вроде
вот я, например, пришел другу страничку править хочу там какой-то эффект MooTools так я ж не должен теперь качать,ставить я просто могу ему написать эффект и показать "вот мол смотри, нравится или нет".
конечно для продакшион проджектов такое использовать не рекоменуется.
вот у меня сразу вопрос.. они конечно сосут статистику, можно даже посмотреть какую, а вот влияет ли это как-то на TRUST сайта, задержку перед началом индексирования нового сайта, продвижение его в песочнице? думаю что нужно поставить эксперимент. вопросов много.. насколько этот сервис интегрирован с другими. наверняка обратная связь есть, только как она работает?