Концепция фреймворка очень распространена как в современной сети, так и в среде разработки программного обеспечения. Для внешнего интерфейса у нас есть фреймворки, такие как Bootstrap и Foundation , для веб-приложений у нас есть фреймворки, такие как Yii и Rails , а для настольных компьютеров (и даже некоторых веб-приложений) у нас есть фреймворки, такие как .NET . И это просто назвать очень маленький и выбрать несколько.
Вообще говоря, фреймворки хороши: они обеспечивают уровень абстракции, с которым мы, как разработчики, можем работать, чтобы легко создавать общие функциональные возможности, такие как вход в систему и аутентификация пользователя, наряду с более конкретным кодом, таким как логика, специфичная для какая бы проблема ни была в том, что программное обеспечение стремится решить.
Короче говоря, Википедия определяет структуру следующим образом :
Программная структура — это универсальная, многократно используемая программная среда, которая обеспечивает особые функциональные возможности как часть более крупной программной платформы для облегчения разработки программных приложений, продуктов и решений. Программные среды могут включать в себя программы поддержки, компиляторы, библиотеки кодов, наборы инструментов и интерфейсы прикладного программирования (API), которые объединяют все различные компоненты для обеспечения возможности разработки проекта или решения.
Как и во многих современных платформах, WordPress ничем не отличается. Конечно, WordPress сам по себе не является фреймворком — это приложение, которое можно расширить с помощью множества API. Но существует целый ряд различных платформ, каждая из которых призвана облегчить бремя написания большого количества повторяющегося кода.
Но хорошо ли это? То есть имеет ли смысл иметь так много вариантов фреймворков, из которых можно выбирать, поскольку это связано с созданием тем WordPress, плагинов или веб-приложений на основе платформы?
Обычно это зависит от того, что вы пытаетесь сделать.
В свойствах Tuts + мы стараемся охватить как можно больше фреймворков — некоторые для WordPress, некоторые для различных языков и платформ, которые были упомянуты ранее — но в этой статье мы не будем рассматривать конкретную среду.
Вместо этого мы рассмотрим преимущества и недостатки выбора платформы при работе с WordPress, чтобы помочь принимать более правильные решения, связанные с созданием сайтов, приложений и других проектов поверх WordPress.
В WordPress полностью возможно смешивать различные фреймворки для достижения конечного результата. В этой статье предполагается, что вы оцениваете, следует ли использовать одну фреймворк для помощи в вашей работе.
Сравнение рамок
Что касается WordPress, в настоящее время (и вообще) существует два типа фреймворков:
- Перетаскивание рамок
- Варианты рамок
Каркасы перетаскивания обычно связаны с созданием пользовательского интерфейса веб-сайта. Часто они представляются в виде различных страниц в панели управления WordPress, которые позволяют упорядочивать предварительно определенные элементы на странице и отображать их в указанном порядке, чтобы пользователь мог их увидеть.
Параметры Frameworks, с другой стороны, обычно используются для специфичной для кода функциональности и обычно предоставляют некоторый тип абстракции для одного или нескольких API WordPress. Это включает, но не ограничивается API настроек, API метаданных (для сообщений, пользователей, комментариев и т. Д.) И даже некоторые API, связанные с шаблонами.
В любом случае, при выборе платформы есть как преимущества, так и недостатки, которые важно учитывать при определении того, собираетесь ли вы работать с этой системой или без нее.
преимущества
Быстрое развитие
Одним из основных преимуществ использования инфраструктуры является скорость, с которой вы можете собрать функциональность.
Иногда люди называют это «быстрым прототипированием», но платформы WordPress достигли такой степени, что при работе с API вы можете легко создавать полноценные интерфейсы, сайты и приложения, а не только прототипы.
Хотя создание управляемых контентом сайтов с помощью WordPress из коробки достаточно просто, многие фреймворки — особенно фреймворки с перетаскиванием — значительно ускоряют создание более сложных макетов страниц.
абстракция
Для фреймворков, которые в первую очередь имеют дело с API-интерфейсами WordPress, фреймворки могут обеспечить хороший уровень абстракции, такой, что большая часть повторяющегося кода, который мы привыкли писать, скрывается внутри фреймворка.
Возможно, один из лучших примеров приходит при взгляде на фреймворки для API настроек . API настроек, хотя и мощный, но и многословный и громоздкий, когда дело доходит до отображения элементов на экране. Фреймворки стремятся решить эту проблему, предоставляя способ более простого создания настроек, опций и настроек с меньшим количеством вызовов функций и более четким кодом.
Конечно, абстракции идут не только с API настроек, но и с другими API. Выбор использования одной из этих платформ может сэкономить много времени и помочь ослабить утомительную природу, возникающую при работе с некоторыми из более повторяющихся аспектов кода на основе WordPress.
Визуальное представление
Другое преимущество использования фреймворков заключается в том, что они помогают преодолеть разрыв между тем, что мы ожидаем, и тем, что действительно происходит.
Это легче всего увидеть в инфраструктурах перетаскивания: у вас есть предопределенный набор областей, с которыми нужно работать, таких как верхние колонтитулы, боковые панели, области содержимого и области нижнего колонтитула, а затем вы помещаете области, где вы хотите, в контейнер. После этого указанные области появляются точно на передней части, так как вы расположили их на внутренней стороне.
То же самое можно сказать и о специфичных для API средах. Хотя визуальная природа написания кода не так ясна, как работа с редактором шаблонов страниц, хорошие фреймворки часто могут предоставлять понятные классы, имена функций и другие средства, которые помогают легче понять, как все движущиеся части Программное обеспечение подходят друг другу.
Один из таких примеров может быть представлен в виде создания настройки в панели управления WordPress. Например, вы хотите ввести textarea которая будет поддерживать только простой текст (то есть разметка или сценарии не допускаются), и вам нужно пометить ее, санировать ее данные, проверять ее данные и отображать их данные. ,
Используя структуру, то, что может потребовать трех разных вызовов функций и как минимум двух обратных вызовов, может быть выполнено за один вызов функции, возможно, с одним или двумя обратными вызовами. Кроме того, имена функций немного более понятны и более показательны для работы, которую они делают, и типа элементов, с которыми они это делают.
Недостатки
Управление зависимостями
С другой стороны, если вы решите использовать фреймворк, вы автоматически создадите зависимость между собой, сторонним кодом и WordPress.
Это означает, что если ваш код основан на фреймворке, а этот фреймворк основан на WordPress, то возможности фреймворка ограничены только самой последней версией WordPress, которую он поддерживает.
Если фреймворк обновляется с WordPress по мере его разработки, и фреймворк выпускается вместе с основными обновлениями WordPress, то синхронизировать код с последними разработками очень просто.
С другой стороны, если фреймворк отстает от самой последней версии WordPress, тогда ваш код может быть обновлен настолько же (и настолько же безопасен и надежен), насколько и самая последняя версия WordPress, которую поддерживает ваша фреймворк.
неодобрение
Другая проблема, связанная с использованием фреймворков, заключается в том, что часто фреймворки представляют собой сложные обертки для существующих функций, существующих в WordPress. Для этого будут времена, когда фреймворки предоставляют доступ к функциям, которые не всегда могут быть доступны при обновлении WordPress.
Скажем, например, у вас есть инфраструктура, которая предоставляет доступ к определенному API, который становится устаревшим в последней версии основного приложения. Кроме того, фреймворк должным образом не поддерживает свой код до следующего цикла выпуска.
Это означает, что код, который вы написали на основе платформы, использует устаревшие вызовы функций. Для одного или двух выпусков это может не иметь большого значения, но как только эта функциональность исчезнет из основного приложения и инфраструктура не решит эту проблему, вы, возможно, не сможете использовать последнюю версию WordPress или некоторые из ее более новые функции, потому что фреймворк не устарел должным образом по сравнению с ядром.
Ограничение возможностей
Фреймворки могут быть действительно мощными, но когда дело доходит до их использования, часто бывает хорошей идеей пойти ва-банк. То есть, когда вы используете фреймворк, обычно неплохо писать весь ваш код, используя фреймворк, а не часть кода, использующего фреймворк, и часть кода, использующего API WordPress.
Другими словами, вы не хотите смешивать код, который вы пишете, с тем, чтобы у вас была небольшая часть кода, которая в некотором роде основана на фреймворке и, как вы знаете, не основана на фреймворке.
В конце концов, цель платформы, как определено ранее, состоит в том, чтобы предоставить абстракцию для универсальной функциональности.
С этой целью, если фреймворк неполон или не хватает функциональности специально для чего-то, что поставляется с ядром WordPress, то у вас остается один из двух вариантов:
- Откажитесь от функции, которую вы хотите использовать, и подождите, пока инфраструктура сделает ее доступной,
- Отойдите в сторону от фреймворка и используйте основной код WordPress вместе с вашим кодом на основе фреймворка, чтобы достичь желаемого результата.
Изначально кажется очевидным, что если среда не предлагает то, что вам нужно, просто используйте то, что предоставляет WordPress. Но когда вы делаете это, вы смешиваете тип кода, который вы пишете, так что вы вводите уровень сложности, когда дело доходит до поддержки программного обеспечения.
Если позже в фреймворке будет представлен набор функций, охватывающих то, что вы когда-то писали как ванильный код WordPress, вам будет предложено обновить указанный код, чтобы он соответствовал фреймворку. С этого момента, если инфраструктура не обновляется постоянно, чтобы оставаться в курсе WordPress, то вы вернулись к проблемам зависимости и устаревания.
Вывод
Нелегко обрисовать в общих чертах все преимущества и недостатки, связанные с использованием фреймворка, не говоря уже о том, чтобы сделать выбор, следует ли вам использовать его или нет, но упомянутые выше моменты являются одними из наиболее распространенных соображений при работе с WordPress и фреймворками. следует подумать, прежде чем выбрать фреймворк и пойти олл-ин с ним.
Кроме того, как уже упоминалось ранее, эта статья не предназначена для аргумента за или против использования фреймворков с WordPress. Вместо этого он призван обеспечить как преимущества, так и недостатки при использовании фреймворков, чтобы помочь вам принять более правильное решение в части, касающейся вашей работы в WordPress.
Как и в случае с чем-либо в процессе разработки, будут компромиссы. Часто все сводится к тому, что вы готовы пойти на компромисс в пользу функциональности, зависимостей и стабильности, при этом балансируя основное программное обеспечение, которое всегда находится в стадии разработки и выпускает основные выпуски примерно каждые шесть месяцев.
В зависимости от характера вашей работы, подход может стать основой; для других не так уж и много. В любом случае, убедитесь, что вы проявили должную осмотрительность при принятии решения о том, использовать ли фреймворк в ваших текущих или будущих проектах.