1. Если фреймворки так просты, то почему на них выше ЗП?
2. Фреймворки и так забиты разработчиками, которые без фреймворка не умеют думать.
3. Адекватные люди — это люди с баблом? Да, у них часто логика типа: вот отвалим дохрена бабла, получим качественный продукт.
Но часто получаем велосипеды на фреймворках.
В конторе, в которой я работал с самописной ЦМС, гребут бабло лопатой, так как хорошее портфолио.
И пофиг, что та ЦМС необновляемая, и пофиг, что с той ЦМС работает только эта студия, и пофиг, что SQL запросы на ней все написаны руками.
Главное навешать клиенту. :)
Кстати да, чем больше людей будет на фреймворках, тем более будут ценны настоящие специалисты.
Я писал и на фреймворках, и на CMS, и на самописи. :)
>Чтобы инвертировать, нам нужно обновить сущность Blog так Doctrine 2 будет знать, что запись может содержать много комментариев. Обновите сущность Blog src/Blogger/BlogBundle/Entity/Blog.php
Хм, а если нам нужно привязаться к сторонней сущности, то нужно править исходники, которые перезатрутся от обновления?
>MVC это архитектура
Я бы сказал, это здравый смысл.
Жирные модели — это все равно, что у курятника будет 10-метровый фундамент… :)
>Делается наследование от класса
Наследование увеличивает сложность, не универсально.
>Думаю это основная причина вашей неприязни фреймворков.
Да :)
>В случае с Yii ни когда не испытывал проблем с документацией.
Она написана как будто для идиотов. Вот именно в Yii. Для создания хоумпаджей. А иногда просто phpdoc
>А страницы не авторизованных пользователей грузятся 5-1мс. Грамотное использование имеющихся механизмов кеширования.
Закешировать страницу целиком — это не совсем грамотно. Да и в 1-5мс я не верю как-то :)
>Nginx прекрасно с этим справляется.
Ну да, нгинкс веб-сервер :)
>Статичная страница на Yii создается 10 строчками кода.
А хедер/футер у такой странички будет?
>По вашему ORM не нужен?
1. Я писал не об ОРМ, а о конструкторах запросов, вроде andWhere/orWhere
2. Но да, я против ОРМ, это лишняя абстракция.
>В роутинге прописывается все достаточно легко. Дальше зависит от ваших рук и головы.
Удалил этот пункт :)
>Точно так же нужные фичи реализуются во фреймворке
Во фреймворках желательно же реализовывать фичи на АПИ самого фреймворка. А часто это усложнено, так как АПИ не предусматривает такого.
>По сути CMS, они есть, см. github.
Интерфес добавления пунктов меню должен быть одинаков.
Каждая CMS на разном фреймворке скорее всего реализует это по своему.
>Виджеты есть.
Я имел в виду программный интерфейс.
>Между 5 и 7й версией PHP тоже не идеальная совместимость.
У меня было только 2 проблемы с 5.2 на 7:
удаленные функции split и mysql_
>Например внутри Yii 1.x с совместимостью все хорошо.
А хотелось бы и 2 с 1. :)
Как в Битриксе.
Да, это сложно.
>Yii::app()->clientScript->registerCssFile(Yii::app()->request->baseUrl. '/css/style.css?'.md5_file(Yii::app()->basePath.'/../css/style.css'));
У меня на работе аутсорсеры, от которых достался код, просто прописали
/>
md5 файла тяжелая ф-я, лучше filemtime()…
>Безопасность и гибкость.
Откуда безопасность?
А гибкость зачастую не нужна.
Понятней обычные массивы GPCS.
>но им не хватает должного раскрытия
>наблюдается сумбурность вообще по многим темам
Я часто пишу «статьи» не целенаправленно, а в результате участия в холиварах :)
Статьи постепенно дополняются.
>адресована Yii. Видимо, потому что там наибольший опыт
На всех работах с фреймворками использовался именно он.
А в статьях он потому, что я его использую на работе сейчас
>часто делаете выводы из частного на общее
Иногда это примеры :)
>для вас является показателем качества первого
Ну. например, возможность sql-инъекций — это к фреймворку, ибо говорится, что он от них спасает. :)
>это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян.
Фреймворки очень сложны и это плата за их универсальность.
Мне такая универсальность не нужна.
А местами не логичны.
>Может вам ЯП надо поменять или какой-то инструмент.
Поэтому я пишу в личных проектах на самописи, которая мне понятна и в которой я хозяин. Мне не нужно гуглить, как в на фреймворке делается то-то и то-то. А это добивает.
1. Меня уровень проверки качества фреймворков не устроил.
Они как китайские молотки, как бренды-пустышки (слышал, у Бугатти днище гниет за 2 года :) ). :)
Почему берут фрейворки? Чтобы быстрее (якобы еще дешевле) состряпать продукт.
В результате выходит черти что.
Использовать фреймворк — это использовать кувалду, где нужен средний молоток.
2. Каждый раз собирать молоток не нужно при грамотном подходе. Можно, конечно, мудохаться и в самописи, каждый раз переизобретая ранее собой же изобретенный велосипед, но это тупо.
Пока нигде потому что:
1. Это пока ноу-хау.
2. Я не хочу распространять код, если он будет труднообновляем. Нужно будет завернуть все в композитор, или как. У меня проблем с обновлениями моих сайтов пока нет, поэтому руки не доходят. :)
3. Я бы еще хотел как-то заработать на этом коде. :) Скорее всего не прямо. Возможно что-то вроде расширенной версии, как у нгинкса. :) В композиторе можно использовать сторонние репозитории с ключем доступа?
4. Как решают проблему конфликта классов сущностей другие? То есть какое-то расширение поставляет с собой какие-то сущности. Как обойти конфликты? Пользовательские сущности выносить в неймспейсы?
5. Перед выпуском в паблик стоило бы подчистить немного легаси код, там пару методов ядра.
6. Нужно написать документацию.
7. Я не знаю, как систему встретят, будут ли пользоваться. Если не будут, то смысла как бы и нет выкладывать. :)
Лично мне тоже без разницы, использует ли кто-то фреймворки.
Те, кто их уже использует, вряд ли перестянет.
Просто фреймворки приподносятся как некая панацея, но это не так. Там говнокода тоже тонны.
Хотя как пристанище говнокодеров (хотя там есть и нормальные программисты) фреймворки выполняют свою роль отлично.
Я против пропаганды фреймворков среди неокрепших умов.
Я навязываю идеологию KISS. :)
А что именно неубедительно? :)
1. Код пока ноу-хау.
2. Там ничего как бы особенного нет:
автолоадинг
события
работа с языками
кеширование
Просто сделано ради решения задач самым простым способом, а не чрезмерно академически.
Ядро в чем-то божественный объект. Но это оправдано, как и в случае с jQuery, нету лишних сущностей.
Фреймворки привносят очень много своих сущностей в разработку.
Я не против фреймворков ради того, чтобы быть против них.
Я против их недостатков.
Часто чтобы решить тривиальную задачу приходится долго мудохаться с фреймворком и его документацией.
Я его не называю таким замараным словом, как фреймворк.
И оно легко для понимания, в отличии от фрейморков.
Содержит всего 50Кб.
У меня используются нативные функции языка, а не так, что каждый фреймворк по сути является новым языком.
А пишущие на фреймворках не умеют самостоятельно строить архитектуру.
Также не мое ядро дергает пользовательский код, а пользовательский код дергает ядро.
2. Фреймворки и так забиты разработчиками, которые без фреймворка не умеют думать.
3. Адекватные люди — это люди с баблом? Да, у них часто логика типа: вот отвалим дохрена бабла, получим качественный продукт.
Но часто получаем велосипеды на фреймворках.
В конторе, в которой я работал с самописной ЦМС, гребут бабло лопатой, так как хорошее портфолио.
И пофиг, что та ЦМС необновляемая, и пофиг, что с той ЦМС работает только эта студия, и пофиг, что SQL запросы на ней все написаны руками.
Главное навешать клиенту. :)
Кстати да, чем больше людей будет на фреймворках, тем более будут ценны настоящие специалисты.
Я писал и на фреймворках, и на CMS, и на самописи. :)
А на фреймворках такая печальная ситуация, что связи со сторонними сущности не сделаешь :)
Вообще наличие этих прописанных связей плохо пахнет.
Комментарии ничего не должны знать о постах и наоборот.
>а бизнес объекты не должны зависеть от внешних зависимостей
Я не понимаю этой фразы… :)
У фреймворков есть маркетплейс, например, как в Битриксе?
>оставляя возможность заменить своей
Написать с нуля? Или отнаследоваться?
С нуля писать наверно плохо. Это потом придется поддерживать актуальность. Это дублирование кода. И есть заповедь: Не плоди сущностей. :)
Наследование? Где будем сохранять ее? В своем бандле? Аннотации (комментарии) не наследуются.
Но с таким фреймворком, как Симфони приходится долго мудохатся даже с простым блогом.
Вот трезвый взгляд на фрейморки:
http://blog.kpitv.net/article/frameworks-1/ (статья обновлена)
Местная публика явно враждебно настроена против альтернативной точки зрения.
Хм, а если нам нужно привязаться к сторонней сущности, то нужно править исходники, которые перезатрутся от обновления?
Мне не нравиться, что для многих вещей нужно делать тройные выверты.
Я бы сказал, это здравый смысл.
Жирные модели — это все равно, что у курятника будет 10-метровый фундамент… :)
>Делается наследование от класса
Наследование увеличивает сложность, не универсально.
>Думаю это основная причина вашей неприязни фреймворков.
Да :)
>В случае с Yii ни когда не испытывал проблем с документацией.
Она написана как будто для идиотов. Вот именно в Yii. Для создания хоумпаджей. А иногда просто phpdoc
>А страницы не авторизованных пользователей грузятся 5-1мс. Грамотное использование имеющихся механизмов кеширования.
Закешировать страницу целиком — это не совсем грамотно. Да и в 1-5мс я не верю как-то :)
>Nginx прекрасно с этим справляется.
Ну да, нгинкс веб-сервер :)
>Статичная страница на Yii создается 10 строчками кода.
А хедер/футер у такой странички будет?
>По вашему ORM не нужен?
1. Я писал не об ОРМ, а о конструкторах запросов, вроде andWhere/orWhere
2. Но да, я против ОРМ, это лишняя абстракция.
>В роутинге прописывается все достаточно легко. Дальше зависит от ваших рук и головы.
Удалил этот пункт :)
>Точно так же нужные фичи реализуются во фреймворке
Во фреймворках желательно же реализовывать фичи на АПИ самого фреймворка. А часто это усложнено, так как АПИ не предусматривает такого.
>По сути CMS, они есть, см. github.
Интерфес добавления пунктов меню должен быть одинаков.
Каждая CMS на разном фреймворке скорее всего реализует это по своему.
>Виджеты есть.
Я имел в виду программный интерфейс.
>Между 5 и 7й версией PHP тоже не идеальная совместимость.
У меня было только 2 проблемы с 5.2 на 7:
удаленные функции split и mysql_
>Например внутри Yii 1.x с совместимостью все хорошо.
А хотелось бы и 2 с 1. :)
Как в Битриксе.
Да, это сложно.
>Yii::app()->clientScript->registerCssFile(Yii::app()->request->baseUrl. '/css/style.css?'.md5_file(Yii::app()->basePath.'/../css/style.css'));
У меня на работе аутсорсеры, от которых достался код, просто прописали
/>
md5 файла тяжелая ф-я, лучше filemtime()…
>Безопасность и гибкость.
Откуда безопасность?
А гибкость зачастую не нужна.
Понятней обычные массивы GPCS.
>наблюдается сумбурность вообще по многим темам
Я часто пишу «статьи» не целенаправленно, а в результате участия в холиварах :)
Статьи постепенно дополняются.
>адресована Yii. Видимо, потому что там наибольший опыт
На всех работах с фреймворками использовался именно он.
А в статьях он потому, что я его использую на работе сейчас
>часто делаете выводы из частного на общее
Иногда это примеры :)
>для вас является показателем качества первого
Ну. например, возможность sql-инъекций — это к фреймворку, ибо говорится, что он от них спасает. :)
>это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян.
Фреймворки очень сложны и это плата за их универсальность.
Мне такая универсальность не нужна.
А местами не логичны.
>Может вам ЯП надо поменять или какой-то инструмент.
Поэтому я пишу в личных проектах на самописи, которая мне понятна и в которой я хозяин. Мне не нужно гуглить, как в на фреймворке делается то-то и то-то. А это добивает.
>так или иначе он у вас есть
Рад, что поняли :)
Какие у вас есть такие проекты?
Они как китайские молотки, как бренды-пустышки (слышал, у Бугатти днище гниет за 2 года :) ). :)
Почему берут фрейворки? Чтобы быстрее (якобы еще дешевле) состряпать продукт.
В результате выходит черти что.
Использовать фреймворк — это использовать кувалду, где нужен средний молоток.
2. Каждый раз собирать молоток не нужно при грамотном подходе. Можно, конечно, мудохаться и в самописи, каждый раз переизобретая ранее собой же изобретенный велосипед, но это тупо.
С ней я и меньше всего работал. :)
Там дальше расшифровывается, что имеется под «Плохой документацией».
1. Это пока ноу-хау.
2. Я не хочу распространять код, если он будет труднообновляем. Нужно будет завернуть все в композитор, или как. У меня проблем с обновлениями моих сайтов пока нет, поэтому руки не доходят. :)
3. Я бы еще хотел как-то заработать на этом коде. :) Скорее всего не прямо. Возможно что-то вроде расширенной версии, как у нгинкса. :) В композиторе можно использовать сторонние репозитории с ключем доступа?
4. Как решают проблему конфликта классов сущностей другие? То есть какое-то расширение поставляет с собой какие-то сущности. Как обойти конфликты? Пользовательские сущности выносить в неймспейсы?
5. Перед выпуском в паблик стоило бы подчистить немного легаси код, там пару методов ядра.
6. Нужно написать документацию.
7. Я не знаю, как систему встретят, будут ли пользоваться. Если не будут, то смысла как бы и нет выкладывать. :)
А Вы сапожник без сапог? :)
>Ну действительно, зачем документация нужна.
А я и не говорю, что не нужна :)
>чтобы не читать весь код, а увидеть суть
Большинство ИДЕ имеет сворачивание кода.
>Вон Вася спился. Давай и я тоже сопьюсь.
Я ж приводил позитивный пример.
>Субъективно
При чем тут субъективно — не субъективно? Это мешание в кучу мух и котлет.
Зачем брать фреймворк и мудохаться с ним, если можно взять CMS?
>Всем пофиг что вы уже полгода пишете крутое ядро.
Подразумевается, что ядро не пишется под каждый проект, а имеется уже наработанное и просто переносится с одного проекта на другой.
>Бизнесу нужен результат.
Бизнесом, как правило, управляют те еще стратеги. :)
>Нужны некие стандарты и документация, дабы любой разработчик быстро сориентировался в проекте
Мои 50 КБ можно изучить за день :)
Стандарты должны быть логичными. Если стандартов слишком много и они не логичны — на них всем начхать.
KISS.
Это кусок контроллера.
Я не вижу смысла разбивать функцию на мелкие функции, если не будет повторного использования.
Зачем плодить абстрации?
>семантическое версионирование
Какая разница, какое версионирование?
Вон Битриксы все совместимы.
>А мне нравятся аннотации.
Аннотации могут нравиться, но это путанье мух с котлетами по факту. )
Те, кто их уже использует, вряд ли перестянет.
Просто фреймворки приподносятся как некая панацея, но это не так. Там говнокода тоже тонны.
Хотя как пристанище говнокодеров (хотя там есть и нормальные программисты) фреймворки выполняют свою роль отлично.
Я против пропаганды фреймворков среди неокрепших умов.
Я навязываю идеологию KISS. :)
А что именно неубедительно? :)
2. Там ничего как бы особенного нет:
автолоадинг
события
работа с языками
кеширование
Просто сделано ради решения задач самым простым способом, а не чрезмерно академически.
Ядро в чем-то божественный объект. Но это оправдано, как и в случае с jQuery, нету лишних сущностей.
Фреймворки привносят очень много своих сущностей в разработку.
Я не против фреймворков ради того, чтобы быть против них.
Я против их недостатков.
Часто чтобы решить тривиальную задачу приходится долго мудохаться с фреймворком и его документацией.
И оно легко для понимания, в отличии от фрейморков.
Содержит всего 50Кб.
У меня используются нативные функции языка, а не так, что каждый фреймворк по сути является новым языком.
А пишущие на фреймворках не умеют самостоятельно строить архитектуру.
Также не мое ядро дергает пользовательский код, а пользовательский код дергает ядро.
О да, это сильно :)