Из практики возник такой вопрос.
К примеру нужно закодировать на 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. Что хошь то и делай.

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

да ORM доставляет проблем, 
количество запросов увеличивается на порядок 
а SQL есть SQL, он и разрабатывался как язык для работы со множествами  

мне всетаки кажется, что создавать подобную "смесь" не стоит... предпочитаю работать напрямую с бд

зы но конечно через минимальную прослойку

Это сообщение отредактировал(а) LeoK - 2.11.2009, 17:21

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

как то это странно    , "некий обскурантизм в действиях" (с)ДМБ

Ну хоть бы написали почему вам так "кажется" ) А то можно подумать, что "не читал, но осуждаю"

ну хотябы потому, что в случае смешанного использования orm и sql собственно теряется сам смысл использования orm. если у нас есть механизм работы с бд, то, имхо, он должен быть один... что если мы например пытаемся встроиться в "прослойку" с бд? например раскидать запросы проксиком с одного сервака на несколько? в случае описанном brother79 придется во первых встраиваться в класс, во вторых перепиысвать custom запросы... если же механизм прослойки один и он минимален, т.е. банальный $db->query($sql), то менять придётся в одном месте и у нас остается один единый интерфейс к бд.

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

А кто говорит о смешанном использовании? Что мешает писать кастомные методы с кастомными запросами (в идеале построенными через конструктор ORM) с кастомным маппингом на объекты?

Масштабирование обычно реализуется именно средствами СУБД. Клиент (php) просто понятия не имеет с какой именно ноды пришли данные.




В любом случае, после работы всех ORM все сводится к выполнению запроса. И выполняется он всегда в одном месте. И изменить логику в этом месте не проблемма (если уж сильно прижало, что маловероятно)


В чем сложность кроме сложности самой ORM? Как-то "сложность ORM" очень слабый аргумент, т.к.:
1. Масштабирование в них предусмотрено "из коробки"
2. Напильник никто не отменял. И, если уж вы придумали нестандартных алгоритм масштабирования -- допилите.

solenko, не думаю, что стоит поднимать холивар на тему orm vs sql  ИМХО orm в "чистом виде" опять таки способ усложнить код + лишний код + усложнение запросов + невозможность оптимизации запросов.

Ответьте мне всего лишь на один вопрос - какой смысл городить "решающуювсезадачи" надстройку над sql? преобразовывая объекты в запросы а потом обратно? Думаю, это просто усложняет логику. База есть база, и лучше чем sql еще ничего не придумали...

Добавлено через 3 минуты и 55 секунд

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


это идеальный случай... ЭФФЕКТИВНОЕ (!!!) бесконечное гориз. масштабирование невозможно без вмешательства в код!.. опять таки повторюсь, что это очень специфично для каждого проекта

 Общие решения как правило подходят для подавляющего большинства проектов. Так что не идут.

 Идеальный случай для подавляющего большинства проектов как раз подойдет.
А вот БЕСКОНЕЧНОЕ гориз. масштабирование - это идеализированный случай )

MyDarkSide,    Что в этом странного?  Всего лиш стараюсь делать не сильную связь между классами. 

1. без фреймворка действительно сложно работать команде в случаях нехватки опыта, отсутствия опыта работы конкретной группы разработчиков , неопытном ПМе, неграмотном тех задании\ проектной документации.  если вся команда неопытна, можно завалить любой проект

2.  если речь идет о личном сайте Васи Пупкина,  его "мегапартале" для друзей, сайта для продажи слонов и т.д.  фреймворки экономят массу времени, но сами разработчики ничему не учатся, т.к. любой фреймворк ограничивает возможности для ускорения разработки ( варианты с переписыванием кусков ядра не рассматриваются, последующий апдейт ядра не должен добавлять N часов работы программисту, просто чтобы сайт работал).

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

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

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

Я не спорю, на своих ошибках учиться можно, только есть поговорка про то, кто и н чьих ошибках учится. Это я к слову нужности изобретания велосипеда.

Ещё раз упомяну, что скорость работы большинства PHP фреймворков узким местом не является.

если не является, то скорее:

много трафа на сайт не только радость =)  у Васи никогда не будет столько уников в онлайне чтобы нагрузить сервер или понадобился ровно работающий кластер серверов

я не хочу сказать что фреймворк плохо, но топик стартер спросил 


да, грузит немного серв имхо 

Угу. А Yahoo answers мегапортал для друзей Джерри Янга )

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

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

Alexm6, 
Да всё там нормально с фреймворками (не со всеми, конечно, но с большинством). Накладной расход на генерацию не так высок. Время загрузки страницы чаще всего выходит в десятки раз больше её генерации из за пренебрежения клиентской оптимизацией. Переход с apache на nginx/php-fpm даёт приличный прирост в количестве одновременно обслуживаемых клиентов. А введение грамотного кеша вообще списывает все мнимые плюсы работы без фреймворка на нет.

 Пишите на static html - грузить не будет.

Фреймвор с никакими libastral не работает, он делает только то, что нужно. Вопрос: на каком основании вы говорите, что он тормозит, если он не выполняет лишних действий?

На основании того, что линейный код будет быстрее работать чем фреймворк. Фреймворк создан чтобы облегчить разработку\понимание системы, за счет производительности.  В нем есть масса кода который нужен только для функциональности ядра или для удобства, это не может не сказываться на производительности. Потери не очень велики при малом количестве запуска кода, ведь не жаль тратить серверные ресурсы ради ускорения разработки в 2 и более раз , но  ситуация меняется если количество запусков кода велико, и даже десятая % разгрузки процессора\памяти, это уже неплохо. 

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



К примеру авторизация, её не впихнуть в кеш, придется работать кодом скриптов при каждом обращении, если при данном телодвижении надо дернуть 50-100кб библиотек фреймворка  ?   или быстрее будет без лишних оберток\классов сделать это ?     
Да, есть акселераторы, которые прекомпилят скрипт. Вопрос в обьме памяти, количестве лишних внутренних вызовов, операций и ифов в конечном исполняемом коде, чем больше, тем медленнее
я кэп очевидность ? )

Alexm6, 
Разработчики дороже железа. Хорошие разработчики много дороже железа.

Изменение кода ядра фреймворка — это самоубийство. Если фреймворк без изменений в ядре нельзя подстроить под себя — это плохой фреймворк.


При использовании APC/XCache не столь критично.


Сделать это будет быстрее с фреймворком. Работать немного быстрее естественно будет лапшекод с формой и её обработчиком в одном файле.

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

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

20% усилий дают 80% результата, остальные 80% усилий — лишь 20% результата

 Линейный код?) Что вы под ним понимаете?
Что мешает использовать фреймворк "линейно"(кроме отсутствия знания фреймворка, конечно же)?

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

Итак, я рассмотрел оба варианта(будет/не будет), в обоих случаях ваш подход проиграл.


 Посчитайте фактически исполненное число строк кода и после этого поймете, что 50-100кб - это бред. Из этого кода выполнится лишь часть. Затраты на парсинг - 0(выш админ не дурак же, чтобы не ставить опкешеры?)

 Его антипод.

 Разработчик стоит допустим 60-100 условных единиц(у.е.).
Допустим за месяц методом спичечных оптимизаций он получит 1-10% прироста.
Допустим сервер стоит 15-30у.е. И он даст 100% прироста.
Считаем и делаем выводы.

Затраты на парсинг не 0, ничего не делается с нулевыми затратами ресурсов
Ваше высказывание очень противоречит логичному :



Говорил о том что этого не будет, о том чтобы не совершать действий которые не нужны для работы


Нормальный сервер стоит 300-500 и более убитых енотов за мес, девелопер дороже, но если серверов в связке несколько десятков накладно выходит, прирост в 10%, даст возможность не ставить лишний сервер, экономим под 5к в год   начальство обычно радуется таким маневрам   ( mchost.ru/dedicated/   сори, не реклама, не самый дешевый, но и не самый дорогой хостинг ). 
ээм, я там делал цитату с пунктом про Васю и его сайты, хост за 15 баксов это для него, а не для нагруженной системы

Alexm6, 

При работе opcode cache они стремятся к нулю.


Естественно медленнее. Тут вопрос не в медленнее-быстрее, а в том, насколько медленнее и существенно ли это.


т.е. вы считаете, что нужно писать всё в 1 файл, совмещая получение и отображение данных?


За 1000$ можно взять очень приличные железки и за 40$/мес., если не меньше, разместить их в нормальном ДЦ.


Нормальный разработчик, который может писать приложения под высокие нагрузки стоит от 1000$ до 3000$ в месяц.
Переписывать проект без фреймворка придётся не менее, чем пару месяцев. Эту пару месяцев заказчик будет терять от 960$ до 2960$ в месяц. Эти деньги можно было бы пустить на покупку серверов, которые увеличат производительность не на 10%, а как минимум на 30—40% (при грамотном проектировании, конечно). В долгосрочной перспективе у нас тоже получится не очень красиво: своего кода без фреймворка больше и его надо документировать. Это дополнительная работа и замедление общего темпа.

 Как это не ноль, если этап парсинга просто пропущен?   

 Ну и не совершайте. С использованием фреймворка.
Вас под дулом пистолета же не заставляют ;)

 Пересчитайте. 10% только от 1 компа(фронтенд). Или у вас зарплата пара сотен?

  
Может быть, но где-то на просторах Сибири?)

nerezus, 
Ну почему сразу на просторах Сибири? Это нормальная нижняя планка, например, для Воронежа. Не все же в пределах МКАД-а 

SamDark, а зачем специалисту работать за такие деньги в оффлайне, когда в сети можно достать в разы больше?
И, тем более, на каких проектах?

nerezus, 
Это уже оффтоп будет. Но могу сказать точно, что работают.
Могу рассказать почему в ICQ/Jabber/MSN/PM

Лапшу он под этим понимает.
Развернутые циклы, минимум условий и вызовов функций.... все в линию.

Да, памяти скушаем чуток больше (раз эдак в 10ть), но выполняться будет код быстрее примерно на целых!!! 5-15%.

Я с таким столкнулся в 95м у матери. В одном из банков девушка-программист создала отчет на FoxPro.
Порядка пары тысяч строк в таком стиле. В общем... тяжко это все.

Когда потребовалось добавить новое поле.... Пообещали сделать не раньше чем через месяц.
Мать, не зная языка, села и сделала с нуля весь отчет за 3 дня. Уместился он в 5ть строк и форму сделанную в генераторе отчетов.

Alexm6, я, пожалуй, внесу свои 5 копеек. Оптимизация кода - это все, конечно, хорошо. Но здесь уже обоснованно говорили, что для большого проекта( как я понимаю, здесь обсуждаются большие системы корпоративного уровня) очень много из фреймворка тебе придется писать руками. А теперь вопрос - будет ли тебе за это платить заказчик, который покупает твое время и заинтересован в скорейшем появлении результата, так как это часть его бизнеса и часто достаточно существенная? Или он просто пошлет тебя подальше и купит более мощный хостинг? Насколько я знаю, заказчики обычно делают какой-то портал или систему под новый бизнес, который открывают. Следовательно, задержка разработки ведет к задержке ввода на рынок некого нового продукта/услуги, которую предоставляет заказчик, и косвенные убытки от такой задержки могут на порядок превосходить затраты на железо.  

Открою страшную тайну, но без фреймворка - руками писать придётся ещё больше  К тому же не факт, что твой велосипед будет нормальный 

brother79,  мы друг друга не поняли))) Я наоборот пытался сказать, что фреймворк сделает решение задачи быстрее) Мож не так выразился)

Инструментом пользуються когда это необходимо
тогда и польза будет

Это сообщение отредактировал(а) Тигер - 23.10.2010, 15:54

С фреймворком на много много быстрее..  

Польза однозначно есть   
Но понимаешь это не сразу, ибо первый серьёзный проект берет как правило в 3 раза больше времени чем на своем велосипеде

Это сообщение отредактировал(а) Muerto - 26.3.2011, 00:35

Muerto, рекомендую попробовать symfony framework, из всех существующих под PHP мне он больше всего понравился. Использую и очень доволен. То, что раньше делалось на PHP4, в рамках готовой системы, в течении недели, на симфони делается за 1-3 дня.


Все это есть, плюс удобный форм-фреймворк и ORM(propel, doctrine). Въехать в него сложновато, особенно без знаний ООП, но после освоения, назад к чистому PHP уже никогда не захочется. А мысли о работе с крупными проектами на чистом PHP, будут вызывать приступы несварения желудка  .

вроде кто-то отстаивал обратное мнение

Мнение дело такое - меняется от нужд и опыта...

Ещё один уровень абстрацкии эт однозначно на любитела...

Но если человек не любит шаблонизаторы - эт ошибка...

Сам "не любил" - потому что не понимал всю прелесть...

А теперь без Haanga и от части Smarty не на шагу =-)

Очень облегчают жизнь, создавая общий язык , упрощая код, и экономя время



Это сообщение отредактировал(а) Muerto - 26.3.2011, 00:59

Это не "на любителя", это необходимость, продиктованная сложностью и объемностью некоторых проектов, где писать все с нуля - это непозволительная роскошь. Достаточно представить себе, например, написание инет-магазина. С нуля возьмется не каждая программерская контора, и стоить это будет не дешево. Все равно в итоге придется писать свой фреймворк для работы с кучей мелочей, типа куков, заголовков, генерацией, валидацией и обработкой форм, управление шаблонами, работа с БД и т.д... И это придется делать, иначе система будет "неуправляемая" (разработчик если не откажется поддерживать ее, то попросит за это немалые деньги  ), т.е. что-то в ней править - будет ночным кошмаром программиста  .
А есть уверенность, в том, что фреймворк, написанный своей, вряд ли очень большой, командой, будет лучше фреймворка, написанного бОльшей командой и отлаженной на протяжении нескольких лет с помощью немалого сообщества его использующего?
Естественно, времени на изучение фреймворка уйдет намного меньше, чем на его написание. Не лучше ли использовать это время более рационально?
Ведь на рынке выиграет тот, кто за меньшие сроки, а значит и деньги, сможет предоставить готовый продукт, полностью покрытый тестами, код которого сможет поддерживать и развивать любой программер, работающий с тем же (открытым)фреймворком.

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

Это сообщение отредактировал(а) KLeonid - 29.3.2011, 02:03

А неее, я рву зубы руками, зачем мне инструменты   

польза: простота доработки сайта

Про ORM:
Пробовал в java, ещё долго просыпался в холодном поту, и через несколько секунд приходило облегчение, что смог таки отказаться от проекта, ничего не потерять и это позади.
Пробовал в 1С Предприятие 8:0 - на удивление всё элегантно, продумано, отлажено. Душа поет!!! Побольше бы таких инструментариев.
PHP - стыдно батенька, но ещё не пробовал. Вот почитал вас, буду искать, с чего начать. Кстати, в процессе создания сайтов разработал свой движок, который успешно использую уже третий год, не жалуюсь. Но хочу таки посмотреть, что попридумывали более серьёзные разработчики.

Мне понравилось название "Kohana"
Кохана - любимая.

Это сообщение отредактировал(а) spbnvb - 14.7.2011, 18:47

Полностью согласен, особенно про работу в команде (иногда такого понапишут что не разберешь)