vagrand

Astin

P.S. Что мешает «меню в сайдбаре» считать из БД в тот же массив? При необходимости как-то его закэшировать в исходном или отрендерреном виде?

Роутинг. Кто какой использует?

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

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

Допустим в Yii до сих пор нет поддержки middlware, а это сейчас в тренде, особенно после выхода PSR-15. Нет, и пока не планируется PSR-7. ActiveRecord вообще считается антипаттерном. И многое другое.

Привыкший кодить по такой схеме человек не сможет грамотно построить приложение на другом фреймворке. А значит он упускает тренды, отстает в развитии и привыкает к bad-practices.

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

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

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

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

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

В общем всем желаю удачи в профессиональной деятельности.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

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

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

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

Есть и такие, я не спорю. Но тогда я не понимаю. Толку от того, что ты знаешь о Yii или Kohana, а платишь все равно деньги за то, чтобы тебе сделали.

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

vagrand, забота об интересах бизнеса это сениорские темы. Не продолжаю мысль, чтобы никого не обижать.

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

Вот когда со временем появится десяток версий своего "фреймворка" или библиотеки (велосипеда), - чуточку несовместимых друг с другом, чуточку с разными фишками и интерфейсами, чуть по-разному кастомизированных под разные проекты. Без документации, версионных change logs, строгого соблюдения мажорных индексов и удерживания "опубликованных" интерфейсов, ради прямой совместимости. Вот тогда посмотрим как запоют велосипедисты.

По уму, каждую свою библиотеку (желательно уникальную, а не велосипед!) нужно выделять в отдельный проект в гитхабе или другой системе контроля версий. Когда их накопится хотя бы штук 5-6, станет ясно, насколько трудно содержать даже несколько библиотек в актуальном состоянии, ready to reuse. Всё о чем написал в предыдущем абзаце, поверьте, довольно большая работа, которую придется выполнять самому. Помимо того, что уже было сказано до меня, про тестирование и пр.

А пока некоторые работают над одним единственным проектом, многое остается неочевидным. Не беда, this is time matter.