Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Для профи > Польза от фреймворков

Автор: MyDarkSide 8.10.2009, 15:26

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

Автор: SamDark 8.10.2009, 16:23

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

Автор: brother79 9.10.2009, 06:08

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

Автор: nerezus 9.10.2009, 09:29

Цитата — Без фреймворка трудно работать в команде. — Документация уже написана. — Код оттестирован миллионами разработчиков. — При грамотном использовании кеша проблем на стороне сервера с производительностью нет.  +1. + Не нужно изобретать велосипеды. + Не нужно изобретать Каркас приложения. + +скорость разработки. + +количество приобретенных ПРАКТИЧЕСКИХ навыков за единицу времени. Цитата А вот с точки зрения производительности и нагрузки на сервер ?  Фреймворк будет не менее производителен мощного велосипеда. А немощный велосипед загнется на самом выполнении задачи, т.к. расширяемость и т.д. явно не будут предусмотрены.

Автор: MyDarkSide 9.10.2009, 10:09

Ага позиция ясна, тогда опять вопросы из практики 1. Цитата(brother79 @  9.10.2009,  06:08 ) полюбому при достаточно сложном проекте в голову лезут мысли организовать что-то типа этих моделей Это правда, но реализация во фреймворке не всегда может быть удачной, работал с CakePHP,  там с объектами предлагается работать как с ассоциативными массивами, т.е. сам фреймворк написан в ОО стиле, но результатом поиска по БД является ассоциативный массив и чтобы сохранить данные опять надо формировать массив, получается фреймворк ОО, а дописывать свой функционал надо в процедурном стиле, а пользовательские классы по сути становятся просто упорядоченным хранилищем процедур)     2. ZF и CakePHP (остальные  не знаю) предлагают парадигму MVC , вопрос: любую ли задачу можно впихнуть в этот шаблон ? 3. Имеется ли принципиальная разница между вариантами с тяжелыми моделями и тяжелыми контроллерами ? 4. Ну и кто с какими рамками работал и какие больше всего понравились?

Автор: SamDark 9.10.2009, 11:15

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, но плотно с ними не работал.

Автор: brother79 9.10.2009, 11:50

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

Автор: MyDarkSide 9.10.2009, 16:16

Цитата(SamDark @  9.10.2009,  11:15 ) 3. Что такое «тяжёлые» модели и контроллеры? может быть не правильно назвал, где большая часть кода размещается. По производительности в инете хвалят  CodeIgniter и Kohana

Автор: nerezus 9.10.2009, 16:55

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

Автор: SamDark 9.10.2009, 17:23

MyDarkSide,  http://www.yiiframework.com/performance Производительность особо ни на что не влияет. PHP вместе с фреймворком редко бывает узким местом.

Автор: Parovoz33 22.10.2009, 01:26

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

Автор: LeoK 30.10.2009, 12:05

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

Автор: brother79 30.10.2009, 12:13

Цитата(LeoK @  30.10.2009,  12:05 ) имхо в больших проектах узкой частью в фреймворках являются ORM, заставляющие манипулировать БД как объектами языка, а не sql запросами. в последствии, при гориз. масштабировании (шарды,прокси) приходится извращаться и получается каша Ничего не мешает руками прописать, то, что сложно городить предоставляемыми ср-вами. Например то же условие, если простые комбинации городяться легко ср-вами фреймворка, то когда надо что-то сложное построить - пишу custom и руками условие.

Автор: Parovoz33 1.11.2009, 23:35

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

Автор: brother79 2.11.2009, 06:06

Цитата(Parovoz33 @  1.11.2009,  23:35 ) В некоторых командах на некоторых проектах бывают жесткие требования - только ORM. Что хошь то и делай.  Ну если это административные правила так сказать, то коммандой и решать что делать, а если сам фреймворк - то даже не знаю, он на то и фреймворк, чтобы была свобода в действиях, но не изобретать велосипед, те, в которых я работал - имели классы, т.е. тот же селект, сначала вызывался коасс, тот вызывал метод, который поэтавпо сначала делал сам селект а потом фетчил, в любом месте этого процесса всегда можно было вмешаться и переписать какой-то этап, если надо что-то специфическое сделать.

Автор: MyDarkSide 2.11.2009, 13:52

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

Автор: LeoK 2.11.2009, 17:18

Цитата(brother79 @  2.11.2009,  06:06 ) Ну если это административные правила так сказать, то коммандой и решать что делать, а если сам фреймворк - то даже не знаю, он на то и фреймворк, чтобы была свобода в действиях, но не изобретать велосипед, те, в которых я работал - имели классы, т.е. тот же селект, сначала вызывался коасс, тот вызывал метод, который поэтавпо сначала делал сам селект а потом фетчил, в любом месте этого процесса всегда можно было вмешаться и переписать какой-то этап, если надо что-то специфическое сделать.  мне всетаки кажется, что создавать подобную "смесь" не стоит... предпочитаю работать напрямую с бд зы но конечно через минимальную прослойку

Автор: OXYGENE 2.11.2009, 20:06

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

Автор: MyDarkSide 3.11.2009, 11:04

Цитата(OXYGENE @  2.11.2009,  20:06 ) Если использую фреймворк то, стараюсь делать классы как можно независимыми от самого фреймвёрка (или хотябы чтоб в дальнейшем делать как можно меньше изменений), для того чтобы их можно было использовать в других проектах или даже в других фреймворках.  как то это странно    , "некий обскурантизм в действиях" (с)ДМБ

Автор: solenko 3.11.2009, 11:28

Цитата(LeoK @  2.11.2009,  16:18 ) мне всетаки кажется, что создавать подобную "смесь" не стоит... предпочитаю работать напрямую с бд Ну хоть бы написали почему вам так "кажется" ) А то можно подумать, что "не читал, но осуждаю"

Автор: LeoK 3.11.2009, 11:43

Цитата(solenko @  3.11.2009,  11:28 ) Ну хоть бы написали почему вам так "кажется" ) А то можно подумать, что "не читал, но осуждаю" ну хотябы потому, что в случае смешанного использования orm и sql собственно теряется сам смысл использования orm. если у нас есть механизм работы с бд, то, имхо, он должен быть один... что если мы например пытаемся встроиться в "прослойку" с бд? например раскидать запросы проксиком с одного сервака на несколько? в случае описанном brother79 придется во первых встраиваться в класс, во вторых перепиысвать custom запросы... если же механизм прослойки один и он минимален, т.е. банальный $db->query($sql), то менять придётся в одном месте и у нас остается один единый интерфейс к бд. в идеале нужно предусматривать в orm логику, позволяющую вследствии использовать к примеру горизонтальное масштабирование, что не так то просто... ввиду сложности как таковой самой orm + еще механизм масштабирования, который в хайлоад проектах может иметь достаточно сложную организацию.

Автор: solenko 3.11.2009, 12:48

Цитата(LeoK @  3.11.2009,  10:43 ) ну хотябы потому, что в случае смешанного использования orm и sql собственно теряется сам смысл использования orm. А кто говорит о смешанном использовании? Что мешает писать кастомные методы с кастомными запросами (в идеале построенными через конструктор ORM) с кастомным маппингом на объекты? Цитата(LeoK @  3.11.2009,  10:43 ) например раскидать запросы проксиком с одного сервака на несколько?  Масштабирование обычно реализуется именно средствами СУБД. Клиент (php) просто понятия не имеет с какой именно ноды пришли данные. Цитата(LeoK @  3.11.2009,  10:43 ) если же механизм прослойки один и он минимален, т.е. банальный $db->query($sql), то менять придётся в одном месте и у нас остается один единый интерфейс к бд. В любом случае, после работы всех ORM все сводится к выполнению запроса. И выполняется он всегда в одном месте. И изменить логику в этом месте не проблемма (если уж сильно прижало, что маловероятно) Цитата(LeoK @  3.11.2009,  10:43 ) в идеале нужно предусматривать в orm логику, позволяющую вследствии использовать к примеру горизонтальное масштабирование, что не так то просто... В чем сложность кроме сложности самой ORM? Как-то "сложность ORM" очень слабый аргумент, т.к.: 1. Масштабирование в них предусмотрено "из коробки" 2. Напильник никто не отменял. И, если уж вы придумали нестандартных алгоритм масштабирования -- допилите.

Автор: LeoK 3.11.2009, 13:03

solenko, не думаю, что стоит поднимать холивар на тему orm vs sql  ИМХО orm в "чистом виде" опять таки способ усложнить код + лишний код + усложнение запросов + невозможность оптимизации запросов. Ответьте мне всего лишь на один вопрос - какой смысл городить "решающуювсезадачи" надстройку над sql? преобразовывая объекты в запросы а потом обратно? Думаю, это просто усложняет логику. База есть база, и лучше чем sql еще ничего не придумали... Добавлено через 3 минуты и 55 секунд Цитата(solenko @  3.11.2009,  12:48 ) 1. Масштабирование в них предусмотрено "из коробки" это задача настолько уникальная для каждого проекта, что общие решения просто идут лесом Цитата(solenko @  3.11.2009,  12:48 ) Масштабирование обычно реализуется именно средствами СУБД. Клиент (php) просто понятия не имеет с какой именно ноды пришли данные. это идеальный случай... ЭФФЕКТИВНОЕ (!!!) бесконечное гориз. масштабирование невозможно без вмешательства в код!.. опять таки повторюсь, что это очень специфично для каждого проекта

Автор: nerezus 3.11.2009, 13:13

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

Автор: OXYGENE 3.11.2009, 22:16

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

Автор: Alexm6 4.11.2009, 14:21

1. без фреймворка действительно сложно работать команде в случаях нехватки опыта, отсутствия опыта работы конкретной группы разработчиков , неопытном ПМе, неграмотном тех задании\ проектной документации.  если вся команда неопытна, можно завалить любой проект 2.  если речь идет о личном сайте Васи Пупкина,  его "мегапартале" для друзей, сайта для продажи слонов и т.д.  фреймворки экономят массу времени, но сами разработчики ничему не учатся, т.к. любой фреймворк ограничивает возможности для ускорения разработки ( варианты с переписыванием кусков ядра не рассматриваются, последующий апдейт ядра не должен добавлять N часов работы программисту, просто чтобы сайт работал). 3. при разработке больших сайтов фреймворк ускоряет получение беты, дает возможность быстро показать клиенту что-то готовое.  Но как правило, все переписывается при первой оптимизации, т.к. в фреймворках упор делается на функциональность, а не на скорость работы скриптов 4. можно и нужно изобретать велосипеды, это процесс обучения. И пусть говорят что 1000 разработчиков отладило код фрейморка, появится 1001 и найдет в том же коде фатальный баг,   1000 обезьян могут ошибаться и как правило ошибаются.  Необходимо четко знать возможности платформы, требования клиентов  и так же предполагаемой нагрузки на систему. В 50% случаев хватает уже готовых модулей для друпала\кейка, еще в 40% можно что-то в них допилить.  оставшиеся 10% это узкая сфера, где фреймворки\цмс не приживаются, т.к. задачи очень нестандартные и сложно вписываются в рамки любого написанного софта

Автор: brother79 4.11.2009, 19:52

Цитата(Alexm6 @  4.11.2009,  14:21 ) 4. можно и нужно изобретать велосипеды, это процесс обучения. И пусть говорят что 1000 разработчиков отладило код фрейморка, появится 1001 и найдет в том же коде фатальный баг,   1000 обезьян могут ошибаться и как правило ошибаются.  Я не спорю, на своих ошибках учиться можно, только есть поговорка про то, кто и н чьих ошибках учится. Это я к слову нужности изобретания велосипеда.

Автор: SamDark 4.11.2009, 20:40

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

Автор: Alexm6 5.11.2009, 12:33

Цитата Ещё раз упомяну, что скорость работы большинства PHP фреймворков узким местом не является.  если не является, то скорее: Цитата 2.  ...  речь идет о личном сайте Васи Пупкина,  его "мегапартале" для друзей, сайта для продажи слонов и т.д.  ....  много трафа на сайт не только радость =)  у Васи никогда не будет столько уников в онлайне чтобы нагрузить сервер или понадобился ровно работающий кластер серверов я не хочу сказать что фреймворк плохо, но топик стартер спросил  Цитата А вот с точки зрения производительности и нагрузки на сервер ? да, грузит немного серв имхо

Автор: solenko 5.11.2009, 12:58

Цитата(Alexm6 @  5.11.2009,  11:33 ) если не является, то скорее: Цитата(Alexm6 @  5.11.2009,  11:33 )  речь идет о личном сайте Васи Пупкина,  его "мегапартале" для друзей, сайта для продажи слонов и т.д.  ....  Угу. А Yahoo answers мегапортал для друзей Джерри Янга )

Автор: Alexm6 5.11.2009, 13:37

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

Автор: SamDark 5.11.2009, 13:51

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

Автор: nerezus 5.11.2009, 13:53

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

Автор: Alexm6 5.11.2009, 14:40

Цитата Вопрос: на каком основании вы говорите, что он тормозит, если он не выполняет лишних действий? На основании того, что линейный код будет быстрее работать чем фреймворк. Фреймворк создан чтобы облегчить разработку\понимание системы, за счет производительности.  В нем есть масса кода который нужен только для функциональности ядра или для удобства, это не может не сказываться на производительности. Потери не очень велики при малом количестве запуска кода, ведь не жаль тратить серверные ресурсы ради ускорения разработки в 2 и более раз , но  ситуация меняется если количество запусков кода велико, и даже десятая % разгрузки процессора\памяти, это уже неплохо.  Изменения кода ядра фреймворка - палка в двух концах, с одно стороны удобно, можно под задачу переписать, сделать более компактным и быстрым. Но в случае обновления фреймворка разработчиками, багфиксах, фиксах безопасности , придется делать изменения в своем коде, сталкиваться с несовместимостью своего кода с новым билдом.  Если время много и сайт только 1 то может показаться что проблемы нет, а если сайтов много и в каждом используется своя модификация ( для увеличения производительности под каждую из задач ), то апдейт и переход на новую версию становится очень болезненным. Цитата  Пишите на static html - грузить не будет. К примеру авторизация, её не впихнуть в кеш, придется работать кодом скриптов при каждом обращении, если при данном телодвижении надо дернуть 50-100кб библиотек фреймворка  ?   или быстрее будет без лишних оберток\классов сделать это ?      Да, есть акселераторы, которые прекомпилят скрипт. Вопрос в обьме памяти, количестве лишних внутренних вызовов, операций и ифов в конечном исполняемом коде, чем больше, тем медленнее я кэп очевидность ? )

Автор: SamDark 5.11.2009, 15:17

Alexm6,  Разработчики дороже железа. Хорошие разработчики много дороже железа. Изменение кода ядра фреймворка — это самоубийство. Если фреймворк без изменений в ядре нельзя подстроить под себя — это плохой фреймворк. Цитата 50-100кб библиотек фреймворка При использовании APC/XCache не столь критично. Цитата или быстрее будет без лишних оберток\классов сделать это ? Сделать это будет быстрее с фреймворком. Работать немного быстрее естественно будет лапшекод с формой и её обработчиком в одном файле. То, что у любого фреймворка есть накладные расходы — это понятно. Но в более-менее сложных приложениях код самого приложения (написанный при помощи фреймворка или без него) выполняется много дольше, чем инициализируется фреймворк и отрабатывают его части. Поэтому, например, та же оптимизация работы с базой путём введения кеша даёт куда больший результат, чем переписывание кода без фреймворка. http://ru.wikipedia.org/wiki/Закон_Парето

Автор: nerezus 5.11.2009, 15:36

Цитата На основании того, что линейный код будет быстрее работать чем фреймворк.   Линейный код?) Что вы под ним понимаете? Что мешает использовать фреймворк "линейно"(кроме отсутствия знания фреймворка, конечно же)? Цитата В нем есть масса кода который нужен только для функциональности ядра или для удобства, это не может не сказываться на производительности.   Следовательно в вашем движке это будет. Но это будет плохо отлажено(ибо потратится меньше времени) и соответственно будет хуже по качеству. Если же этого не будет, то вы потеряете часть функционала, который нужен(иначе вы бы просто не использовали данные части фреймворка). Итак, я рассмотрел оба варианта(будет/не будет), в обоих случаях ваш подход проиграл. Цитата К примеру авторизация, её не впихнуть в кеш, придется работать кодом скриптов при каждом обращении, если при данном телодвижении надо дернуть 50-100кб библиотек фреймворка  ?  Посчитайте фактически исполненное число строк кода и после этого поймете, что 50-100кб - это бред. Из этого кода выполнится лишь часть. Затраты на парсинг - 0(выш админ не дурак же, чтобы не ставить опкешеры?) Цитата я кэп очевидность ? )  Его антипод. Цитата Разработчики дороже железа. Хорошие разработчики много дороже железа.  Разработчик стоит допустим 60-100 условных единиц(у.е.). Допустим за месяц методом спичечных оптимизаций он получит 1-10% прироста. Допустим сервер стоит 15-30у.е. И он даст 100% прироста. Считаем и делаем выводы.

Автор: Alexm6 5.11.2009, 16:03

Цитата  Посчитайте фактически исполненное число строк кода и после этого поймете, что 50-100кб - это бред. Из этого кода выполнится лишь часть. Затраты на парсинг - 0(выш админ не дурак же, чтобы не ставить опкешеры?) Затраты на парсинг не 0, ничего не делается с нулевыми затратами ресурсов Ваше высказывание очень противоречит логичному : Цитата Вопрос в обьме памяти, количестве лишних внутренних вызовов, операций и ифов в конечном исполняемом коде, чем больше, тем медленнее Цитата  Следовательно в вашем движке это будет. Но это будет плохо отлажено(ибо потратится меньше времени) и соответственно будет хуже по качеству. Если же этого не будет, то вы потеряете часть функционала, который нужен(иначе вы бы просто не использовали данные части фреймворка). Говорил о том что этого не будет, о том чтобы не совершать действий которые не нужны для работы Цитата  Разработчик стоит допустим 60-100 условных единиц(у.е.). Допустим за месяц методом спичечных оптимизаций он получит 1-10% прироста. Допустим сервер стоит 15-30у.е. И он даст 100% прироста. Считаем и делаем выводы. Нормальный сервер стоит 300-500 и более убитых енотов за мес, девелопер дороже, но если серверов в связке несколько десятков накладно выходит, прирост в 10%, даст возможность не ставить лишний сервер, экономим под 5к в год   начальство обычно радуется таким маневрам   ( mchost.ru/dedicated/   сори, не реклама, не самый дешевый, но и не самый дорогой хостинг ).  ээм, я там делал цитату с пунктом про Васю и его сайты, хост за 15 баксов это для него, а не для нагруженной системы

Автор: SamDark 5.11.2009, 16:43

Alexm6,  Цитата Затраты на парсинг не 0, ничего не делается с нулевыми затратами ресурсов При работе opcode cache они стремятся к нулю. Цитата Вопрос в обьме памяти, количестве лишних внутренних вызовов, операций и ифов в конечном исполняемом коде, чем больше, тем медленнее Естественно медленнее. Тут вопрос не в медленнее-быстрее, а в том, насколько медленнее и существенно ли это. Цитата Говорил о том что этого не будет, о том чтобы не совершать действий которые не нужны для работы т.е. вы считаете, что нужно писать всё в 1 файл, совмещая получение и отображение данных? Цитата Нормальный сервер стоит 300-500 и более убитых енотов за мес За 1000$ можно взять очень приличные железки и за 40$/мес., если не меньше, разместить их в нормальном ДЦ. Цитата прирост в 10%, даст возможность не ставить лишний сервер, экономим под 5к в год  Нормальный разработчик, который может писать приложения под высокие нагрузки стоит от 1000$ до 3000$ в месяц. Переписывать проект без фреймворка придётся не менее, чем пару месяцев. Эту пару месяцев заказчик будет терять от 960$ до 2960$ в месяц. Эти деньги можно было бы пустить на покупку серверов, которые увеличат производительность не на 10%, а как минимум на 30—40% (при грамотном проектировании, конечно). В долгосрочной перспективе у нас тоже получится не очень красиво: своего кода без фреймворка больше и его надо документировать. Это дополнительная работа и замедление общего темпа.

Автор: nerezus 5.11.2009, 17:16

Цитата Затраты на парсинг не 0, ничего не делается с нулевыми затратами ресурсов  Как это не ноль, если этап парсинга просто пропущен?    Цитата Говорил о том что этого не будет, о том чтобы не совершать действий которые не нужны для работы  Ну и не совершайте. С использованием фреймворка. Вас под дулом пистолета же не заставляют ;) Цитата Нормальный сервер стоит 300-500 и более убитых енотов за мес, девелопер дороже, но если серверов в связке несколько десятков накладно выходит, прирост в 10%, даст возможность не ставить лишний сервер, экономим под 5к в год  Пересчитайте. 10% только от 1 компа(фронтенд). Или у вас зарплата пара сотен? Цитата Нормальный разработчик, который может писать приложения под высокие нагрузки стоит от 1000$    Может быть, но где-то на просторах Сибири?)

Автор: SamDark 5.11.2009, 17:57

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

Автор: nerezus 5.11.2009, 18:06

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

Автор: SamDark 5.11.2009, 18:42

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

Автор: Simpliest 5.11.2009, 21:22

Цитата(nerezus @  5.11.2009,  14:36 )  Линейный код?) Что вы под ним понимаете? Лапшу он под этим понимает. Развернутые циклы, минимум условий и вызовов функций.... все в линию. Да, памяти скушаем чуток больше (раз эдак в 10ть), но выполняться будет код быстрее примерно на целых!!! 5-15%. Я с таким столкнулся в 95м у матери. В одном из банков девушка-программист создала отчет на FoxPro. Порядка пары тысяч строк в таком стиле. В общем... тяжко это все. Когда потребовалось добавить новое поле.... Пообещали сделать не раньше чем через месяц. Мать, не зная языка, села и сделала с нуля весь отчет за 3 дня. Уместился он в 5ть строк и форму сделанную в генераторе отчетов.

Автор: Severyanin 3.3.2010, 10:56

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

Автор: brother79 14.5.2010, 08:24

Цитата(Severyanin @  3.3.2010,  14:56 ) Но здесь уже обоснованно говорили, что для большого проекта( как я понимаю, здесь обсуждаются большие системы корпоративного уровня) очень много из фреймворка тебе придется писать руками. Открою страшную тайну, но без фреймворка - руками писать придётся ещё больше  К тому же не факт, что твой велосипед будет нормальный

Автор: Severyanin 10.6.2010, 17:28

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

Автор: Тигер 23.10.2010, 15:54

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

Автор: kolorimage 9.12.2010, 21:07

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

Автор: Muerto 30.1.2011, 01:29

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

Автор: KLeonid 22.3.2011, 03:06

Muerto, рекомендую попробовать symfony framework, из всех существующих под PHP мне он больше всего понравился. Использую и очень доволен. То, что раньше делалось на PHP4, в рамках готовой системы, в течении недели, на симфони делается за 1-3 дня. Цитата Люблю фронт контроллер+раутер и все, мне больше для счастья не нужно  Все это есть, плюс удобный форм-фреймворк и ORM(propel, doctrine). Въехать в него сложновато, особенно без знаний ООП, но после освоения, назад к чистому PHP уже никогда не захочется. А мысли о работе с крупными проектами на чистом PHP, будут вызывать приступы несварения желудка  .

Автор: SneG0K 22.3.2011, 05:45

Цитата(Muerto @  30.1.2011,  00:29 ) Php и так по сути дела шаблонизатор, ещё один уровень абстракции эт на любителя там всякие Smarty вроде кто-то отстаивал обратное мнение

Автор: Muerto 26.3.2011, 00:41

Цитата(SneG0K @ 22.3.2011,  05:45) Цитата(Muerto @  30.1.2011,  00:29 ) Php и так по сути дела шаблонизатор, ещё один уровень абстракции эт на любителя там всякие Smarty вроде кто-то отстаивал обратное мнение Мнение дело такое - меняется от нужд и опыта... Ещё один уровень абстрацкии эт однозначно на любитела... Но если человек не любит шаблонизаторы - эт ошибка... Сам "не любил" - потому что не понимал всю прелесть... А теперь без Haanga и от части Smarty не на шагу =-) Очень облегчают жизнь, создавая общий язык , упрощая код, и экономя время

Автор: KLeonid 29.3.2011, 02:01

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

Автор: Sentox 1.5.2011, 22:56

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

Автор: phpmas 21.5.2011, 00:17

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

Автор: spbnvb 14.7.2011, 18:41

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

Автор: alekseyroot1 15.6.2012, 22:36

Цитата(brother79 @ 9.10.2009,  06:08) Ещё забыл добавить, что не надо заниматься велосипедостроением, т.к. например та же работа с mysql построенна на моделях, в тех фреймворках, в которых я работал, т.о. если будешь писать сам, полюбому при достаточно сложном проекте в голову лезут мысли организовать что-то типа этих моделей, а зачем этим заниматься - когда всё давно уже сделанно. Ну и остальные моменты - тоже также, просто я про модели заговорил, т.к. в своё время нечно подобное разрабатывал на билдере, а когда увидел фреймворк - сильно удивился, что всё давно готово для php и не надо этот велосипед изобретать. Если писать самому - то придётся делать что-то типа фреймворка, только подсебя, иначе сложный проект не построишь. Полностью согласен, особенно про работу в команде (иногда такого понапишут что не разберешь)

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)