Минусы и плюсы нового фреймворка PHP 5

Хотя мы старые добрые друзья с PHP, начиная с PHP 3 дней, и я зарабатывал этим на жизнь, я всегда считал себя студентом, а не экспертом, и мне всегда нравилось учиться на опыте других людей. Когда я столкнулся с проблемой, я счел более логичным поискать по чужим стопам, прежде чем пытаться изобретать велосипед. Это помогло мне выработать точку зрения на то, где использовать существующие, где ими манипулировать и где спроектировать колесо с нуля; «как думать» для краткости. За свою жизнь программиста я столкнулся с несколькими проблемами, работал над различными проектами как самостоятельно, так и в составе команды, и, помимо собственного опыта, я имел возможность услышать, как другие программисты подходили к конкретной задаче программирования или логической задаче, даже большинство из них были ежедневными и повторяющимися, особенно для себя! Я уверен, что первая структура приложения началась в результате того же чувства: мы делаем какие-то общие вещи в каждом новом проекте, и большинство из нас использует некоторый повторно используемый код и пишет обертки вокруг него, если у нас достаточно опыта, но помещать их в единое целое всегда возникает как новая проблема с каждым новым проектом, поскольку объем нового проекта редко бывает одинаковым. как и предыдущий, и если ваш последний проект занял, скажем, восемь месяцев, если вы человек, который не помнит всего, что он сделал за всю свою жизнь, как я, это также будет означать еще одну кривую обучения, даже если учитель себя и кривая повторно относительно короткий… и бесполезный… Пройдя этот этап, несколько лет назад, вскоре после появления PHP 5, я начал искать хорошую основу, подходящую для проектов любого масштаба, и с большим удовольствием увидел Я был не одинок с большинством своих мыслей, и с большим видением люди уже начали кодировать некоторые фреймворки для PHP 5, чтобы использовать преимущества объектно-ориентированных функций, чтобы иметь более повторно используемый код, но, увы, это все еще было PHP 4 дня для всех остальных. Если бы я использовал их фреймворки без каких-либо возражений, мне все равно нужно было сначала искать возможности сервера, и большую часть того, что я написал, мне нужно было развернуть, поэтому мне нужно было еще какое-то время работать с моими собственными решениями. день я услышал о Ruby On Rails и шаблоне MVC. Это звучало логично, но я не мог больше бороться за использование Ruby и его защиту, и вскоре после этого я встретил CodeIgniter. Я чувствую, что у меня почти такое же мнение об этом с моего первого дня: Боже, это было что-то полезное! Он также работал с PHP 4 и позволял программисту держать все в форме. Самое главное: не слишком сложно погрузиться. Это определенно было чем-то новым для меня, и, поскольку CI является одной из самых популярных платформ в настоящее время, я думаю, что это актуально для очень многих других программистов. Я считаю, что CI была отправной точкой для также несколько других фреймворков, однако со временем я почувствовал, что в нем не хватает многих важных для меня функций, поскольку жизнь продолжалась, в то время как эти моменты можно было бы рассматривать как «особенности» для некоторых других. Просто чтобы назвать некоторые из них, у них были хорошие функции обработки и проверки формы, но они не были полностью отделены от остальной логики вашего программирования, поскольку они хотели проверять любые данные по принципалу, а не только формы, тогда как в реальной жизни большинство задачи проверки предназначены для данных, поступающих из форм. Другим было то, что они не хотели использовать генераторы кода, скорее всего, потому, что хотели оставить кодировщика свободным в своих решениях, или, возможно, по другой причине. Но для меня их использование является преимуществом, а не недостатком, если это оставлено на ваш выбор. Чтобы назвать их, я также встретил Symphony, который был ответом на использование генератора кода, а также Cake. Cake был строгим, Symphony — лучше, и, наконец, Zend. Я просто хочу задать простой и честный вопрос и закрыть дело Zend: если бы он не назывался «Zend», сколько людей действительно его использовали бы? Итак, со временем, Я пришел к тому моменту, когда я был почти уверен в том, что мне действительно нужно от фреймворка как программисту: — Документация (без нее я не могу понять, что это действительно не ракетостроение.) — Производительность. (Особенно важно, когда вы имеете дело с сайтами с высокой посещаемостью.) — Удобство использования. (Мы люди. Мы будем использовать его, а не роботы.) — Разделение логики: Требуемая реализация MVC, чтобы заставить меня писать хороший код. Я очень ленивый человек, и если у меня есть соединение с БД внутри контроллера, я бы предпочел его использовать. В дополнение, но не обязательно: Разделение логики формы и проверки: Мои формы и мои валидаторы «должны знать о друг друга». Если я буду «определять» форму, мой валидатор также должен иметь возможность использовать эти определения, но это должно быть очень либертарианским способом: для этого я не должен определять макет формы в моем общем виде, но пусть люди используют мои компоненты формы так, как они хотят, в своем дизайне, даже если они могут быть сгенерированы автоматически. — Как следствие предыдущего: программиста нельзя заставлять использовать какой-либо механизм шаблонов, но при этом сохранять права на использование преимуществ хороший механизм кэширования.-Возможности Ajax: PHP-программист почти мертв без Ajax. Ему нужна рука. — Генератор кода со всеми ajaxified хорошими возможностями разбиения на страницы, сортировки и проверки. — Хорошая библиотека для любой задачи (которой у меня нет в версии 1.0). Это мои стандарты, которые должны выйти из коробки. , и я едва мог видеть их вместе в других рамках. Я полагаю, что добился большинства из вышеперечисленных пунктов с более ранней версией 1.0 и все это сам, и если вы, программист, читающий эти строки, внесете свой вклад, у нас может быть гораздо больше.