Использование Frameworks

[Дмит_рий]

Использование Frameworks

Кто-нибудь использует php frameworks? Насколько быстрее и удобнее идет разработка? Как потом с поддержкой приложений и их модификацией? Не ограничивает ли использование framework?

 

[atv]

Это с такими вопросами вы собираетесь 20 человеколет прокручивать? Да щас все сидят на фрэймворках, не на чужих так на своих.

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

 

[Дмит_рий]

Автор оригинала: atv
Это с такими вопросами вы собираетесь 20 человеколет прокручивать?

Да.

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

Каким фреймворком пользуетесь вы? Расскажите про свой опыт. Что скажете о Zend framework?

 

[Patrick (KT)]

Zend framework. Почитал посмотрел - хороший framework, есть русская документация, что плюс, разбирайся и пользуйся! А лучше пиши свой, тогда и проблем с поддержкой и модификацией не будет.

 

[atv]

Каким фреймворком пользуетесь вы? Расскажите про свой опыт. Что скажете о Zend framework?

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

Мой опыт ничем вам не поможет. Я вообще интересуюсь событийно-ориентированными фрэймворками. Там совсем другая парадигма, отличающаяся от MVC. Если захотите тратить на это время, тогда можно поговорить.

По Zend-у тут была целая ветка, поищите по форуму.

 

[Дмит_рий]

Автор оригинала: atv
Мне кажеться, так вы ничего себе не подберёте.

Я ничего себе и не подбираю.

Мой опыт ничем вам не поможет.

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

 

[Romantik]

Нда, только вот в ТЗ инвесторам тогда пишите точную дату- 20 лет, а не всякое там виртуальное! =)

 

[atv]

Сколько времени разработчики потратили на изучение чужого фреймворка и привыкание к новому стилю разработки?

Не могу сказать, я работаю на своём фрэймворке.

Мне приходилось разбираться с чужими фрэймворками - занимало 2-3 дня на разбирательство с архитектурой, после чего мог приступать к работе. В течении работы дополнительно осваивал конкретные классы, которые требовались для работы. Соответсвенно, полностью я не изучал ни один фрэймворк, только то, что непосредственно потребовалось в работе.

Насколько быстрее и удобнее идет разработка?

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

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

Как потом с поддержкой приложений и их модификацией?

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

Не ограничивает ли разработчиков использование фреймворка?

Только если они не собираются вникать в него. В противном случае, всё в руках разработчиков - дописать, переписать и т.д. Разработчики LIMB, например, так и поступают с фрэймворком WACT. Они или связываются с разработчиками WACT, или сами доделывают необходимую функциональность.

 

[Alexandre]

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

зависит от опыта, от месяца до двух

- Насколько быстрее и удобнее идет разработка?

зависит от фреймворка, но увеличивает в разы

- Как потом с поддержкой приложений и их модификацией?

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

- Не ограничивает ли разработчиков использование фреймворка?

естественно ограничивает.

ИМХО: По этому - каждый специалист пишет фреймворк под себя. Лично я, например из ZendFramework буду использовать только фильтры, все остальное мне на данном этапе просто не нужно, а тогда зачем тогда неиспользуемыми классами засорять код???.

Я вообще не использую фреймворки, использую некоторый набор классов разных разработчиков. После проникновения ООПшностью, я понял, что использование готовых фреймворков только ограничивают тебя, так как в разных задачах разная архитектура классов. Я не имею ввиду стандартные промо и корп. сайты, которые делаются со скоростью штука в неделю.

Под каждую задачу надо писать свой спицифический код, а специфику фреймворки не учитывают.

 

[StUV]

Дмит_рий

- Сколько времени разработчики потратили на изучение чужого фреймворка и привыкание к новому стилю разработки?

зависит от опыта (от 30 мин - до ... =)

- Насколько быстрее и удобнее идет разработка?

зависит от уровня соответствия фреймворка поставленной задаче
имхо, высказанное мнение "однозначно быстрее" неверно - может быть и медленнее - тем более если никто из разработчиков не использовал ранее выбранный фреймворк + вся команда не участвовала в проектах уровня рассматриваемого (я про ваш предыдущий топик - речь ведь об этом ?)

- Как потом с поддержкой приложений и их модификацией?

как всегда - не верте сказкам
если серьезно - зависит от соответствия полученного кода проектной документации (и т.д., и т.п.)

- Не ограничивает ли разработчиков использование фреймворка?

нет
относительно нет (т.е. зависит от опыта, как и в первом пункте)

 

[atv]

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

Событийно-ориентированный подход позволяет избавиться от архитектурной зависимости.

Под каждую задачу надо писать свой спицифический код, а специфику фреймворки не учитывают.

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

 

[Alexandre]

Событийно-ориентированный подход позволяет избавиться от архитектурной зависимости

но зато включает тормоза! Надо это использовать там, где действительно надо ( POS системы, настольные приложения).

Я честно говоря не представляю как реализовывается событийно-ориентированный подход на пхп. Кто использовал прадо - не лучшего мнения об этом. Это не лучшее развитие направления, в сторону Дотнетовских примочкек. Эффект имеет место, если Событийно-ориентированный подход встроен в Enginie, иначе стрельба из Царь-пушки по воробьям.

-~{}~ 18.08.06 10:34:

Под каждую задачу надо писать свой спицифический код, а специфику фреймворки не учитывают.

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

Опять, это зависит от задач. я повторяю, что речь идет не о

стандартные промо и корп. сайты, которые делаются со скоростью штука в неделю.

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

Эта самая специфика находиться на уровне приложения

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

зависит от опыта (от 30 мин - до ... =)

А какое кол-во классов можно освоить за 30 мин? Максимум 1-2. Полноценное изучение нормального фреймворка - дело не одного дня. Вспоминается случай, когда я посчитал, что зная базовый С++ и имея хороший опыт программирвоания на Дельфях я смогу быстро (в течение недели) пересесть на DevStudio. Однако - это у меня заняло более месяца. Не надо себя переоценивать. Это особенно опасно в больших проектах.

-~{}~ 18.08.06 10:47:

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

Мне вспоминается слова одного разработчика ЦМС: "делаешь делаешь, стараешься все собрать воедино и автоматизировать, чтоб было удобно, а потом окажется это все так тормозит." так что самое главное "не ошибиться в выборе на этапе строительства архитектуры"

 

[atv]

Надо это использовать там, где действительно надо

Для того приложения, которое собирается делать автор топика, это действительно надо. Без той структурированности кода, которую даёт событийно-ориентированный подход, они погрязнут в своём коде. А поднять производительность можно и другими способами, если понадобиться.

Кто использовал прадо - не лучшего мнения об этом.

Вот именно в прадо отсутствуют события приложения, которые позволяют избежать архитектурной независимости. Там присутствуют только события объектов. Этого тоже немало, но, недостаточно.

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

Своё что? Фрэймворк? Тогда какой смысл. Вывод - нужно менять платформу, подход программирования, писать на ассемблере и т.д.

Например очень специфичные вещи - кеширование. Кеширование может быть двух-трех видов. А если использовать оба вида сразу???

А что ж тут специфичного? В PEAR давно есть, и может быть применено для разных задач, а не только к одной.

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

Вот именно, о чём я и говорил автору топика в самом начале. Он не поверил

Я честно говоря не представляю как реализовывается событийно-ориентированный подход на пхп.

http://php.com.ua/ru/articles/other/

 

[Alexandre]

http://php.com.ua/ru/articles/other/

значить мы имели разные понятие о событиях. Если в этом ключе, то вполне согласен.

хотя если возратиться к примеру в статье, то на сегоднешний день, функции onInput() checkLetters() объединяются в класс, как методы, а

global $message;

выносится как локальная переменная класса (свойство private). Так что статья или пример к ней морально устарели.

Своё что? Фрэймворк? Тогда какой смысл. Вывод - нужно менять платформу, подход программирования, писать на ассемблере и т.д.

производительность Си и ассемблера где-то одного порядка, а трудозатраты несопоставимы. Писать полностью на Си WEB проект, затраты на много превысят разумные границы. Можно написать отдельные части проекта... Но мне кажется мы просто думаем о разных вещах подразумевая одни и теже слова, как например у нас вышло с термином "событийно-ориентированный подход ".
Однако, из пяти изученных мною фреймворков, мне не подошел ни один. Нужно много дописывать или перерабатывать. А потом, что такое фреймворк - это набор готовых классов для быстрой разработки приложения. Такой набор у меня в принципе есть, а что-то дописывается (переделывается). С переходом на пхп5, отпадает надобность в части классов, разработанных в ранних фреймворках, что-то концептуально изменилось, например DOM, что-то появилось например PDO, SPL. И соответственно подходы разработки стали немного иные, нежели пхп 3-4.

-~{}~ 18.08.06 14:37:

А что ж тут специфичного? В PEAR давно есть, и может быть применено для разных задач, а не только к одной.

что есть - не подходит.

 

[atv]

Так что статья или пример к ней морально устарели.

Это, конечно, не по теме этого топика. В статье объясняется суть событий, а классы или нет - это уже конкретная реализация. Одну и ту же абстракцию можно реализовать разными подходами, но суть абстракции от этого не меняется. Кстати, по этой ссылке есть другая статья "Событийно-ориентированные приложения в РHР".

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

Не совсем. В этой статье (http://wiki.agiledev.ru/doku.php?id=frameworks) более подробно раскрывается значение фрэймворка.

 

[StUV]

Alexandre

А какое кол-во классов можно освоить за 30 мин? Максимум 1-2.

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

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

не забывай - ЯП это только средство
фреймворк - это надстройка над ЯП и по сути то же самое

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

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

-~{}~ 18.08.06 17:19:

Событийно-ориентированный подход позволяет избавиться от архитектурной зависимости.

любой подход накладывает архитектурное ограничение
по определению

 

[atv]

любой подход накладывает архитектурное ограничение
по определению

Спорное утверждение. Пишите тогда определение.

 

[StUV]

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

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

если у тебя все объекты-сущности инкапсулируют собственное поведение и управляются внешней логикой приложения - это уже не есть чистый событийный подход...