Я почти завершил проект PHP, используя MVC, jQuery и Ajax. Это чистый PHP-проект. Я не использую никаких фреймворков в коде. Я хотел бы изменить это. Я обнаружил, что, проведя некоторые исследования, Yii оказался одним из лучших каркасов.
Возможно ли каким-то образом перенести чистый PHP-проект на Yii?
Если да, то как это сделать? Какие шаги я должен выполнить, чтобы уменьшить рабочую нагрузку и пользоваться преимуществами, которые представляет собой инфраструктура Yii?
Я – новичок в Yii, любые идеи оценены.
TL; DR: Не делайте этого. Это действительно ужасная идея.
Выполняя некоторые исследования, я обнаружил, что Yii оказывается одной из лучших структур.
Какое странное исследование вы сделали. Мне бы хотелось увидеть материалы. Особенно, поскольку я бы оценил его как 3-ий худший PHP-фреймворк. Только превзошел в этом ужас от CodeIgniter и CakePHP.
И причиной этого является крайне плохое качество кода, которое эта структура отображает в сочетании с плохой практикой, которую она увековечивает.
Из вашего описания очевидно, что вы НЕ знакомы с этой базой и не имеете никакого предыдущего опыта.
В управлении проектами есть тема: управление рисками . И в этом случае добавление ранее неиспользуемой структуры на заключительных этапах проекта будет представлять собой высокую вероятность того, что высокий риск воздействия, который также, благодаря мудрецу проекта, полностью исключен .
Это означает, что есть действительно хороший шанс, что что-то пойдет не так. И когда это произойдет, это, скорее всего, утонет проект. Или, по крайней мере, отбросить данные выпуска на значительный промежуток времени.
В идеальных мировых рамках используются для упрощения повторяющихся задач развития за счет некоторой производительности. Это те задачи, которые вы выполняете в начале проекта. Вы не находитесь в начале проекта. Это означает, что вы не получите никаких преимуществ от этого «маневра».
Как я уже отмечал ранее, есть также причины не только для того, чтобы избежать добавления рамки к существующему проекту, но и из-за того, почему следует избегать Yii в частности.
Весь ваш контроллер расширит класс CController , который расширяет CBaseController , который расширяет CComponent
Все ваши «модели» расширят эфир CActiveRecord или CFormModel , который расширяет CModel , который расширяет CComponent .
Обе цепочки содержат статические переменные и выполняют статические методы на множестве разных классов. Сочетание этих факторов сделает отладку чрезвычайно сложной и утомительной.
Существует несколько форм глобального состояния. То, что обычно знают люди на PHP, это global переменные. Но это не единственная форма. Каждый раз, когда у вас есть класс, содержащий static переменную, он также создает глобальное состояние, которое может (и почти всегда – будет) приводить к тому, что кажущийся несвязанный экземпляр таинственным образом взаимодействует.
Использование глобального состояния является основным механиком. Вы увидите статические вызовы по всей кодовой базе, а файл конфигурации Yii не будет функционировать без глобального состояния.
И каждый раз, когда вы вызываете Yii::app() вы получаете доступ и / или меняете его.
Это делает unittesting невозможным для приложений Yii. И отладка превращается в использование grep для всего проекта.
Когда вы создаете приложение в Yii. Он становится привязанным к нему. Вы не можете выполнять части своего приложения, не запуская полную структуру. В основном это связано с статическим вызовом, который вы добавляете в свой код.
Каждый раз, когда вы добавляете статический вызов в свой собственный код, этот фрагмент кода привязывается к имени класса . Это, по сути, плотная связь.
Как вы могли заметить (надеюсь), есть и другой способ, как добиться такого же эффекта – использование new оператора. Это еще один способ связать определенный код с определенным именем класса.
Каким бы ужасным ни была конфигурация проекта Yii, файл конфигурации был хорошо намеченным жестом. Наименее опасный способ введения внешнего кода и замены существующих компонентов в такой перепутанной кодовой базе.
Но, к сожалению, это сфокусировано на проблемах, вызванных отсутствием интерфейсов и существующей связью.
Одним из компонентов, который разработчики попытаются заменить, является CUrlManager . В основном из-за способа передачи дополнительных параметров.
Интерфейс в ООП указывает контракт между двумя экземплярами. Он позволяет определить возможности экземпляра, методы, которые могут использоваться другими. Когда его нет, в большой базе кода вы оставляете догадки, какие методы требуются, а какие нет.
В случае компонентов Yii проблема еще более усугубляется из-за статического вызова и глубокого наследования. Вышеупомянутый CUrlManager расширяет CApplicationComponent , который расширяет CComponent . Также тот же файл определяет CUrlRule и CBaseUrlRule .
Когда вы пишете замену, вам нужно написать какой-то код, подключить его в конфигурации, а затем проверить его, запустив приложения. Таким образом, вы знаете, какой метод (или параметр) вам нужно добавить.
По сути, это метод разработки «save-an-see-what-blows-up» .
Yii не реализует MVC или любые шаблоны дизайна, созданные MVC. То, что он называет «MVC», может быть описано как шаблон ActiveRecord-Template-Logic .
Вместо того, чтобы иметь надлежащий слой модели (да, это должен быть слой), создатель (ы) Yii выбрал коллекцию активных записей и оберток форм. Это заставляет логику приложения принудительно вводить «контроллеры».
С другой стороны, у вас есть прославленные шаблоны вместо правильных экземпляров представления для хранения логики представления. Это несколько смягчается использованием виджетов , но вместо этого они страдают от нарушений SRP , потому что виджеты вынуждены содержать биты логики представления и выполнять частичную визуализацию. Остальная логика представления заканчивается снова в контроллерах.
И чтобы все ухудшилось, «контролерам» также приходится иметь дело с авторизацией . Обычно это будет означать, что всякий раз, когда вы меняете схему доступа, вам нужно будет пройти через каждый экземпляр CController чтобы проверить, нужно ли его изменять.
Это не MVC. Это путаница с именами, взятыми из шаблона проектирования MVC и ударами по некоторым компонентам.
В рамки также входит незначительная проблема, которая не заслуживает отдельного раздела:
Определение более одного класса для файла:
Это будет раздражать довольно быстро, потому что будут классы, которые можно сортировать в файлах классов с полностью несвязанными именами файлов. Это будет означать, что отладка нередко требует использования поиска.
Шлепан на «модулях»:
По его мнению, модули, добавленные в структуру после факта. Поэтому, когда вам нужно установить модуль по умолчанию, вам придется установить его в параметре файлов конфигурации, который называется 'defaultController' .
Я на самом деле недавно преобразовал веб-сайт шаблона MVC, который я построил с нуля в Yii. Потребовалось некоторое время, чтобы все исправить, но, честно говоря, это того стоило. Я смог отбросить много кода, потому что уже были расширения Yii, которые делали то, что мне нужно. Я бы также предложил сохранить вашу базу данных, потому что вы можете создавать контроллеры и модели с помощью Gii, что сэкономит вам массу времени.
Я не знаю никаких быстрых решений. Это зависит от того, как был написан код. У вас есть база данных и ваши взгляды, так что это не совсем новый проект, когда вы входите в yii. Yii создаст для вас модели баз данных. У вас уже есть мнения из существующего проекта. Напишите контроллер и действия и при необходимости измените представления.
попробуйте эти ссылки, поскольку они относятся к одной и той же проблеме.
Как преобразовать старый проект oop в Yii
советы по переносу существующего сайта на Yii
Drupal для миграции Yii
Поскольку у вас уже есть код в mvc, вам будет намного легче мигрировать. Однако при миграции на Yii, поскольку он может легко генерировать контроллер и модель с помощью gii, вы можете воспользоваться этим.
Итак, сначала создайте контроллер и модель с помощью gii, затем вы можете заменить свой существующий код (замените я намереваюсь, замените ваш код на определенную функцию в контроллере и модели) на встроенный контроллер и модель, чтобы функциональность вашего сайта до сих пор работает. Вы можете соответствующим образом изменить свое мнение. Но это не будет большой работой.
Вы можете просто зарегистрировать свой скрипт для ajax, jquery и css. Они тоже будут работать.
И да, Yii – лучшая структура, так что примите столько же выгоды, сколько сможете.
Спасибо, Уджваль
В этом проекте вы преобразовали php в структуру yii. Это действительно легко для вас, если вы выполните следующий шаг.
Поскольку у вас уже есть код в mvc, вам будет намного легче мигрировать. Однако при миграции на Yii, поскольку он может легко генерировать контроллер и модель с помощью gii, вы можете воспользоваться этим.
во-вторых, если ваша база данных точна, то 50% работы завершаются. Когда вы создаете операцию CRUD с помощью gii, тогда автоматически создавайте модель-view-controller. Если вы создаете mvc в php, тогда это benifit для вас.
В-третьих, вы можете просто включить свой скрипт для ajax, jquery и css. Те будут работать, а вы создадите папку в темах (CSS, JS, AZAX, BOOTSTRAP).
4-Protected-> view-> layout, где вы можете изменить свою тему … это все
вы также помогаете http://www.yiiframework.com/doc-2.0/guide-intro-yii.html
если вы думаете, что мой ответ поможет вам тогда оценить меня … спасибо.