Из практики возник такой вопрос.
К примеру нужно закодировать на PHP+MySQL  сложный нестандартный посещаемый проект типа 
социальной сети и или пошаговой стратегии и т.п.
Имеет ли смысл использовать готовые фреймворки типа ZF или CakePHP (и все остальные до кучи) ?
С одной стороны они дают выигрышь во времени разработки, при условиях, что задачу можно впихнуть в предлагаемую фреймворком парадигму и  что все разработчиик достаточно хорошо с ним знакомы.
А вот с точки зрения производительности и нагрузки на сервер ?
Естественно, что  код  написаный под конкретную задачу лучше фреймворка с этой точки зрения, но может быть так только кажется ? 

MyDarkSide, 
Есть.

— Без фреймворка трудно работать в команде.
— Документация уже написана.
— Код оттестирован миллионами разработчиков.
— При грамотном использовании кеша проблем на стороне сервера с производительностью нет.

Ещё забыл добавить, что не надо заниматься велосипедостроением, т.к. например та же работа с mysql построенна на моделях, в тех фреймворках, в которых я работал, т.о. если будешь писать сам, полюбому при достаточно сложном проекте в голову лезут мысли организовать что-то типа этих моделей, а зачем этим заниматься - когда всё давно уже сделанно. Ну и остальные моменты - тоже также, просто я про модели заговорил, т.к. в своё время нечно подобное разрабатывал на билдере, а когда увидел фреймворк - сильно удивился, что всё давно готово для php и не надо этот велосипед изобретать. Если писать самому - то придётся делать что-то типа фреймворка, только подсебя, иначе сложный проект не построишь.

 +1.
+ Не нужно изобретать велосипеды.
+ Не нужно изобретать Каркас приложения.
+ +скорость разработки.
+ +количество приобретенных ПРАКТИЧЕСКИХ навыков за единицу времени.

 Фреймворк будет не менее производителен мощного велосипеда. А немощный велосипед загнется на самом выполнении задачи, т.к. расширяемость и т.д. явно не будут предусмотрены.

Ага позиция ясна, тогда опять вопросы из практики

1.


Это правда, но реализация во фреймворке не всегда может быть удачной, работал с CakePHP,  там с объектами предлагается работать как с ассоциативными массивами, т.е. сам фреймворк написан в ОО стиле, но результатом поиска по БД является ассоциативный массив и чтобы сохранить данные опять надо формировать массив, получается фреймворк ОО, а дописывать свой функционал надо в процедурном стиле, а пользовательские классы по сути становятся просто упорядоченным хранилищем процедур)    

2. ZF и CakePHP (остальные  не знаю) предлагают парадигму MVC , вопрос: любую ли задачу можно впихнуть в этот шаблон ?
3. Имеется ли принципиальная разница между вариантами с тяжелыми моделями и тяжелыми контроллерами ?
4. Ну и кто с какими рамками работал и какие больше всего понравились?

MyDarkSide, 
1. CakePHP (в особенности 1.1) — не очень удачный пример.
2. MVC можно применить к 90% задач под веб. ZF вообще ничего не предлагает. Он даёт средства. Один мой товарищ сделал на ZF event-driven модель с модулями.
3. Что такое «тяжёлые» модели и контроллеры?
4. Пара-тройка велосипедов, ZF, CakePHP, CodeIgniter, Yii, Drupal. Понравились: Yii, Drupal, CodeIgniter. ZF только как набор библиотек. CakePHP не понравился. Сейчас остановился на Yii. Также пробовал Kohana, Symfony, Limb, Django, но плотно с ними не работал.

Мы осстановились на Symfony, правда я пока 1.2 и 1.3 плотно не изучал, и пишу на 1.0, ибо ограничения на хотстинге у нас по версии пхп. Меня всё устраивает, вплодь до того, что иногда возникает чувство, что не я похожую модель реализовывал, а они все мои мысли слизали 

может быть не правильно назвал, где большая часть кода размещается.

По производительности в инете хвалят  CodeIgniter и Kohana

MyDarkSide, большая часть кода размещается нигде. Код равномерно распределен.

MyDarkSide, 
http://www.yiiframework.com/performance

Производительность особо ни на что не влияет. PHP вместе с фреймворком редко бывает узким местом.

Это сообщение отредактировал(а) SamDark - 9.10.2009, 17:24

Мне тоже кажется что производительность мало зависит от фреймворка и PHP. Производительность сервера зависит от железа и рук программиста. Но! Мое мнение все же такое, некоторые так увлекаются ООП и фреймворками, что создаются некоторые сложности. Когда с одного проекта на другой переходишь очень сложно врубиться. Да и просто когда классов становится под сотню, то просто путаешься, где что и как. Фреймворк хорош тем, что поставляет каркас. Остальное все - это уже дело вкуса, можно найти много готовых решений на все случаи жизни в самых разных репозитариях на просторах интернета, и даже совместно их использовать.

имхо в больших проектах узкой частью в фреймворках являются ORM, заставляющие манипулировать БД как объектами языка, а не sql запросами. в последствии, при гориз. масштабировании (шарды,прокси) приходится извращаться и получается каша

зы
ничего лучше sql для sql нету, orm - это для маленьких (опять же имхо)

Это сообщение отредактировал(а) LeoK - 30.10.2009, 12:10

Ничего не мешает руками прописать, то, что сложно городить предоставляемыми ср-вами.

Например то же условие, если простые комбинации городяться легко ср-вами фреймворка, то когда надо что-то сложное построить - пишу custom и руками условие. 

В некоторых командах на некоторых проектах бывают жесткие требования - только ORM. Что хошь то и делай.

Ну если это административные правила так сказать, то коммандой и решать что делать, а если сам фреймворк - то даже не знаю, он на то и фреймворк, чтобы была свобода в действиях, но не изобретать велосипед, те, в которых я работал - имели классы, т.е. тот же селект, сначала вызывался коасс, тот вызывал метод, который поэтавпо сначала делал сам селект а потом фетчил, в любом месте этого процесса всегда можно было вмешаться и переписать какой-то этап, если надо что-то специфическое сделать.