функциональное: когда блок «а» делает работу типа «а», блок «б» делает работу типа «б».
распределение по данным: есть поток данных и все блоки его колят, как-то синхронизируясь.
повторюсь и я… затраты на поиск/изучение готового решения часто сопоставимы с написанием своего, и еще я не против фрейморков как таковых, я против того, чтоб отказываться от велосипедов.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
Как я уже написал выше, я сам иду по другому пути — наследую компоненты фреймворка и добавляю в них ту функциональность, которой лично мне нехватает
впринципе я не против такой позиции, просто у меня другая. Ну не находил я фраймов которые имеют привлекательные мне слои абстракции, а ведь с этого все начинается.
Я понял вас, понял ваши аргументы, но они мне кажутся недостаточно значительны чтобы избрать фреймворк и присоединиться к таким людям, да я изучаю фреймворки, но не сажаю на них свои большие проекты.
я предпочитаю библиотеки: инструменты которые отлажено решают узкий класс задач, которые избавлены от необходимости жить в особой среде фреймворка — это мой выбор, а то ваш, у нас нет точек конфронтации.
затраты на введение фраймворка сопоставимы с затратами на работу без него — это основная проблемма.
язык 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 С++.
вы сможете добавить специи по своему выбору, если вы работаете в команде, то у вас больше шанцев изменить рецепт до приготовления, так чтоб ни у кого из членов команды не было аллергии на отдельные его части.
вы можете использовать сезонные и свежие овощи! например, если только что появилась возможность использовать наймспайсы, вы их любите, то вы уже можете включить их в состав своих блюд! я очень сомневаюсь, что шеф повар вашего любимого Фреймворка обладает достаточной гибкостью чтоб сделать это.
худеем — нужно меньше калорий… я думаю, что вам не зачем тащить с собой всю инфраструктуру Фреймворков просто, чтоб оно работало «как всегда» или на «всякий случай», вы же готовите!, а значит, на столе не должно быть ничего лишнего.
«используйте только соевый соус» — подумайте должны ли вы так строго соблюдать рецепт?? а что если вам хочется кетчуп? отказаться от таматов? ограничения вызванные использованием готового фраймворка иногда оказываются очень серьезными и вам не нужными.
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды минусы:
нет сообщества, которое обсудит ВАШУ проблемму
велика вероятность «глупых» ошибок
вы варитесь в собственном соку — не знаете новых методов если всегда все делаете сами
Сложно предать проект другим людям
Плюсы:
вы имеете полную свободу выбора, все что вы делаете вы можете сделать как вам угодно
в любом месте вы можете вставить новое решение и будете знать как это изменит вашу систему
вы можете решить любую проблему! вы автор системы, вам подвластны решения
все органичения вам подвластны
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)
ну занятная штука. интересно было посмотреть, интересный метод, использовать не собираюсь, но автору метода респект, задача так сказать с точки зрения самой задачи весьма занятная и интересно решена.
распределение по данным: есть поток данных и все блоки его колят, как-то синхронизируясь.
В ближайшее время я напишу (седня завтра) статейку про очередной велосипед, поэтому попрошу вас зайти ко мне в други чтоб я мог вам дать почитать до публикации.
впринципе я не против такой позиции, просто у меня другая. Ну не находил я фраймов которые имеют привлекательные мне слои абстракции, а ведь с этого все начинается.
Я понял вас, понял ваши аргументы, но они мне кажутся недостаточно значительны чтобы избрать фреймворк и присоединиться к таким людям, да я изучаю фреймворки, но не сажаю на них свои большие проекты.
я предпочитаю библиотеки: инструменты которые отлажено решают узкий класс задач, которые избавлены от необходимости жить в особой среде фреймворка — это мой выбор, а то ваш, у нас нет точек конфронтации.
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
штука какраз в том что когда делается что-то новое, то не всегда есть решение, и без велосипедов чуть чуть отличных никак!
язык 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`е тока не давно сан сделал полную среду свою, а до этого так же были склады решений и все рылись в них, достаточно вспомнить эпопею с аспектным программированием.
почему я использую свои разработки и предпочитаю изучать патерны, а не Фреймворки?
это только общие замечания, есть частные, например, вы знаете, что в вашем случае контекст задачи подразумевает упрощение какого — либо механизма, в рамках фрайм ворка это упрощение (логики, абстракций, производительности) обычно сложно сделать, но на вашей кухне вы можете себе позволить это.
я выделяю такие плюсы/минусы:
свои велосипеды
минусы:
Плюсы:
в итоге вы рискуете, но вы гарантированы от того чтоб зайти в тупик, а с Фреймворком (особенно большим вы не гарантированны)