ZendFramework или крик души

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

ну там и yii2 тоже запланирован. Тока симфони опять каким нибудь монстром будет по типу зф.

Да вроде обещают более экономное использование. Чего стоит только динамическая загрузка модулей, а не 100500 инклюдов как в зф.

Хм, интересно. Нужно будет потискать в свободную минутку. Хотя жопой нутром чую - нативный код всё-равно быстрее, лучше, универсальней...если время старта проекта не очень критично.

в yii динамическая подгрузка.

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

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

Создатели симфонии2 пытаются убедить в обратном. Кроме того там хороший профайлер. И поддержка полюбившейся мне MongoDB. Хотя, возможно в yii2 тоже будет нечто подобное, но об этом вроде неизвестно.

---------- Сообщение добавлено в 03:01 ---------- Предыдущее сообщение было в 01:44 ----------

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

PHP:

SELECT * FROM table_name PROCEDURE ANALYSE();

- Часто, практически постоянно вижу использование типа INT для целых значений рассчитывая видимо на то, что в их таблице будет более 4 миллиардов записей, все VARCHAR почему-то считают что лучше поставить в 255 символов "на всякий случай?". И прочие некорректные применения типов.

- Использование SELECT * FROM table_name, когда все поля не нужны. Модернизируя систему в эту же таблицу может попасть ещё с десяток полей, и с каждым разом использование первого примера будет всё расточительнее. Где-то видел такой запрос для выборки одного поля из таблицы более 20 мб.

Ещё десятки примеров халатности можно привести только здесь, не говоря уже о самом коде приложения. А потом пытаются такую поделку ускорить, применяя всякие костыли и экономя на спичках. А вот если делать такое, да на таком же фреймворке то тогда вообще пиз""ц грустно получается. Впрочем, именно так и поступают создатели se4. Но это так, лирическое отступление было. Тоже своеобразный крик души.

ну если не пиздят, то круто, да.

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

Это как? dbal что ли? Или pdo? Так это и без фреймворков используется многими.

К счастью само оно таблицы не создает. Но работает-то оно с ними как? Универсально, а не оптимально.

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

Все упирается в том, что ОRМ пожирает много ресурсов. Не отрицаю, хотя грамотные орм и не пожирают очень уж много, но все ж с ручной оптимизацией не сравнить. Я говорю, что в фреймворках запросы можно писать в ручную. И при чем тут орм? Грубо говоря примерно так:

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

Жуткий пример. Хотя и немного непонятный. Получается что он выгребает всю таблицу, а потом сортирует. Грустно если в таблице более 500к записей. И станет совсем плачевно если там есть BLOB поля с данными.

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

фреймворк это не только орм. Фреймворк это далеко не орм.

Прописная истина. орм, ооп и т.д.это стили, а их реализация может где угодно, и какой угодно (в пределах модели).

Ага, с модулем аукциона. Просто видимо под понятием "чистый sql" у нас сначала были разные понятия. Я вот принял это за dbal.