Что вам нужно от framework'а? (опрос PHP|mag)

[Rammstein]

Что вам нужно от framework'а? (опрос PHP|mag)

International PHP Magazine провёл опрос "Что вам нужно от framework'а?". В качестве ответа предлагалось 7 вариантов:
* O-O структура MVC
* ORM / Active Record
* Хорошая структура контроллера
* Совместимость с Ajax (Ajax Interoperability)
* Возможность объединённого тестирования
* Open Source/Free лицензии
* Безопасность
* Хорошие хэлперы
* Scaffolding (затрудняюсь ответить что это значит, но вариант такой был )
В результате получилось, что всё, впринципе, должно быть в меру, но особы выделились пункты об ОО структуре MVC и о лицензии.

Полные результаты можно найти здесь.

 

[whirlwind]

> O-O структура MVC
> ORM / Active Record
> Хорошая структура контроллера
> Возможность объединённого тестирования
+ CC | BPD
+ TDD support

PS. Про безопасность не понял - по моему не в тему вопрос. Неужели кто то согласиться юзать "небезопасный" ФВ?

надо нам тоже такой опрос провести

 

[crocodile2u]

Особо порадовал пункт "Совместимость с Ajax". Как же это фреймворк может быть несовместим с Ajax?

 

[whirlwind]

crocodile2u оно не совсем как совместимость переводится

 

[bgm]

Rammstein, crocodile2u
Всё же, скорее, не "совместимость", а "взаимодействие".

 

[crocodile2u]

Ну да, я уже потом прочел оригинал. Но вопрос, в общем, остается в силе.

 

[Rammstein]

Там скорее имеется ввиду наличие инструментов (встроенных), и минимальное время подключения возможностей AJAX.

 

[Alexandre]

1) O-O структура MVC
2) ORM / Active Record
3) Хорошая структура контроллера
4) Совместимость с Ajax (Ajax Interoperability)
5) Возможность объединённого тестирования
6) Open Source/Free лицензии
7) Безопасность
8) Хорошие хэлперы

1 - однозначно
2 - с появлением PDO, это становится лишним... ORM становится эффективной лишь при интеграции в качестве модуля. ORM - надстройка над SQL, которая требует детального вникания, короче для написания гибких запросов необходимо либо отакзаться от ORM, либо ORM должен превратится м монстра и придется еще изучать один язык
3- неважно, многие возлагают функции контроллера на mod_rewrite, мне кажется это эффективнее.
4 - поддержка AJAX желательна
5 - TDD является плюсом
6 - однозначно
7 - однозначно, хотя непонятно что под этим понисается... Этот вопрос наслолько уже истерли до дыр, что "опасные скрипты" писать уже как-то и не получается.
8 - конечно, сложность современных фреймворк систем настолько возросла, что многих отпугивает их использование, только из-за плохого или не полного хелпа.
9 - не понял что это такое...

 

[whirlwind]

PDO - это ОО драйвер доступа к БД. К ORM он имеет такое же отношение как Creole или ODBC.

 

[Alexandre]

надо нам тоже такой опрос провести

только не +или минус, а определить по 10-бальной шкале важность каждого фактора.

-~{}~ 28.09.06 12:23:

PDO - это ОО драйвер доступа к БД. К ORM он имеет такое же отношение

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

вот вопрос для обсуждения
какую нагрузку должен выдерживать ФВ
- 1 000 посещений
- 5 000 посещений
- 10 000
- 25 000
- 45 000
- 70 000
- 100 000

 

[crocodile2u]

Alexandre
Не понял последний пост. Нагрузку выдерживает сервер, приложение - но никак не фреймворк.

 

[whirlwind]

> какую нагрузку должен выдерживать ФВ

Я могу сопоставить нагрузку и кривизну/прямизну рук разработчика или нагрузку и качество CMS, но вот как может коррелировать нагрузка и CMF?

Alexandre

Если интересно, вот здесь http://phpclub.ru/talk/showthread.php?s=&threadid=91066&rand=101 мы обсуждали что такое ORM.

 

[Rammstein]

whirlwind
crocodile2u
В большинстве случаев, кэширование, классы для работы с БД - это и есть фреймворк, и если они не правильно реализованы, то фреймворк будет слабее в плане нагрузок.

Alexandre
8 helpers Но документация, дейтвительно, не менее важный фактор, чем все остальные... Почему интересно в опросе такой пункт отсутствовал.

 

[Alexandre]

Если интересно, вот здесь http://phpclub.ru/talk/showthread.p...66&rand=101 мы обсуждали что такое ORM.

whirlwind в этом топике можешь найти мое мнение...

Я могу сопоставить нагрузку и кривизну/прямизну рук разработчика или нагрузку и качество CMS, но вот как может коррелировать нагрузка и CMF?

корреляция самая что ни есть непосредственная, наводящеее понятие "время отклика" если ни о чем не говорит, то спор бесполезен.
Конечно, первоочередное предпочтение - железо, но кривизна/прямизна рук разработчика CMF не последнее место.

-~{}~ 28.09.06 17:00:

В большинстве случаев, кэширование, классы для работы с БД - это и есть фреймворк, и если они не правильно реализованы, то фреймворк будет слабее в плане нагрузок.

Rammstein +1 в точку попал!!!

 

[whirlwind]

>корреляция самая что ни есть непосредственная, наводящеее понятие "время отклика" если ни о чем не говорит, то спор бесполезен.

Я просто не пойму немного. Никто же не говорит - "давайте сядем и напишем крутой ФВ с нуля". Как самостоятельный продукт ФВ не имеет смысла, он обязательно удовлетворяет требования множества продуктов на его основе. Разве нельзя сделать вывод, что в ФВ попадают только проработанные вещи и что "время отклика" в большинстве случаев зависит от того продукта, который написан с использованием ФВ? Или тут имеется в виду CMS? Если я не о том, извините, не дорос наверное.

 

[crocodile2u]

так. посмотрим, посмотрим...

Тормозят в основном SQL-запросы, файловые операции. И если у вас большие объемы данных, а индексы расставлены неграмотно, то никакой ФВ вас не спасет от тормозов. Да, я определенно соглашусь, что разница в производительности двух одинаковых приложений, созданных на основе разных ФВ, однозначно будет. Но я уверен, что бОльшая часть этой разницы кроется в конкретном приложении, а не в ФВ. Например, возьмем PEAR:B. Много раз говорилось, что пакет довольно тяжелый и, скажем так, небыстрый (прошу только не разводить флейм по конкретно этому поводу). Тем не менее, при его использовании все тормоза упираются в структуру БД, индексы, объемы данных и т.д. Использование PDO или функций mysql_* - не даст резкого прироста производительности.

Да, кстати. Я вовсе не считаю PEAR:B фреймворком. А пример привел к тому, что, имхо, не будет большой разницы в производительности, если фрейморк будет юзать PEARB или, скажем, PDO.

 

[Krishna]

crocodile2u

PEARB это не фреймворк
фреймворк это например Xaraya
которая делает всё - асбтрагирование от СУБД, проверку прав, вывод шаблонов и их кеширование, обеспечивает модульность архитектуры и контролирует их взаимодействие, предоставляет различные базовые модули, навроде Динамических Данных и так делее. Разработка становится легким и приятным делом (размумеется после того, как вы освоите этого монстра), однако, производительность проекта разработанного на Xaraya оставляет желать лучшего

 

[whirlwind]

> которая делает всё

а что же тогда делает программист?

 

[crocodile2u]

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

 

[Krishna]

whirlwind
ну "всё" из рутинных операций

Программист пишет бизнес логику своего модуля