Вопрос по php – Миграция проекта чистого PHP в фреймворк Yii

9

Я почти закончил проект PHP, используя MVC, jQuery и Ajax. Это чистый проект PHP. Я не использую никаких фреймворков в коде. Я хотел бы изменить это. Проведя некоторые исследования, я обнаружил, что Yii оказывается одним из лучших фреймворков.

Можно ли как-то перенести чистый PHP-проект на Yii?

Если так, то как это сделать? Каким шагам мне следует следовать, чтобы уменьшить рабочую нагрузку и пользоваться преимуществами платформы Yii?

Я новичок в Yii, все идеи приветствуются.

Ваш Ответ

4   ответа
4

Я на самом деле недавно преобразовал сайт шаблонов MVC, который я создал с нуля, в Yii. Потребовалось некоторое время, чтобы все это настроить, но, честно говоря, оно того стоило. Я смог выбросить много кода, потому что уже были расширения Yii, делающие то, что мне нужно. Я бы также посоветовал вам сохранить вашу базу данных, потому что вы можете создавать контроллеры и модели, используя Gii, что сэкономит вам массу времени.

-1

В этом проекте вы конвертировали php в yii framework. Это действительно легко для вас, если вы выполните следующий шаг.

Поскольку у вас уже есть код в mvc, вам будет намного проще его перенести. Однако при переходе на Yii, поскольку он может очень просто генерировать контроллер и модель с помощью gii, вы можете воспользоваться этим.

во-вторых, если ваша база данных точна, то 50% работы завершены. когда вы создаете операцию CRUD с помощью gii, то автоматически создаете модель-представление-контроллер create.if вы создаете mvc в php, тогда это вам выгодно

в-третьих, вы можете просто включить свой скрипт для ajax, jquery и css. Они будут работать так же, как вы создадите папку в темах (CSS, JS, AZAX, BOOTSTRAP).

макет с четырьмя защитами & gt; view->, где вы можете изменить свою тему ... вот и все

Вы также помогаете www.yiiframework.com/doc-2.0/guide-intro-yii.html

если вы думаете, что мой ответ поможет вам, тогда оцените меня ... спасибо.

3

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

попробуйте эти ссылки, поскольку они относятся к той же проблеме.

Как конвертировать старый проект OOP в Yii

советы по переносу существующего сайта в Yii

Drupal для Yii Migration

Error: User Rate Limit Exceeded
47

TL;DR : Не делай этого. Это действительно ужасная идея.


The Rant ..

"Framework" is not a magic sauce, that you add to a project, to make it better and shinier.

Doing some research i found Yii turns out to be one of the best frameworks out there.

Какое странное исследование вы провели ... Я хотел бы увидеть материалы. Тем более, что я бы оценил его как 3-й худший фреймворк PHP. Только превзошел в этом ужасность CodeIgniter и CakePHP.

И причина этого заключается в крайне плохом качестве кода, который этот фреймворк показывает, в сочетании с плохой практикой, что он увековечивает.

Why avoid migration?

Из вашего описания очевидно, что вы НЕ знакомы с этим фреймворком и не имеете предыдущего опыта работы с ним.

В управлении проектами появилась тема:управление рисками, И в этом случае добавление ранее неиспользованной структуры на заключительных этапах проекта будет представлять собойhigh probability high impact риск, который также, из-за мудрости проекта, полностьюunmitigated.

Это означает, что есть очень хороший шанс, что что-то пойдет не так. И когда это произойдет, это, скорее всего, потопит проект. Или, по крайней мере, отодвинуть данные релиза на значительный промежуток времени.

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

Why not Yii?

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

The inheritance nightmare

Весь твой контроллер будет расширять классCController, который расширяетCBaseController, который расширяетCComponent

Все ваши & quot; модели & quot; расширит эфирCActiveRecord или жеCFormModel, который расширяетCModel, который расширяетCComponent.

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

Global state

Есть несколько форм глобального государства. Люди в PHP обычно знают, чтоglobal переменные. Но это не единственная форма. Каждый раз, когда у вас есть класс, который содержитstatic переменная, она также создает глобальное состояние, которое может (и почти всегда) будет вызывать, казалось бы, не связанный экземпляр загадочно взаимодействовать.

Использование глобального состояния является основной механикой. Вы увидите статические вызовы по всей кодовой базе и Yii'ам.конфигурационный файл не будет функционировать без глобального состояния.

И каждый раз, когда вы звонитеYii::app() Вы получаете доступ и / или меняете его.

Это делает юнит-тестирование невозможным для приложений Yii. И отладка превращается в упражнение использованияgrep на весь ваш проект.

Tight coupling

Когда вы создаете приложение в Yii. Это становится связанным с этим. Вы не можете выполнить части своего приложения без запуска полной структуры. В основном это происходит из-за статического вызова, который вы добавляете в свой код.

Каждый раз, когда вы добавляете статический вызов в свой собственный код, этот фрагмент кода привязывается кname of the class, По сути, это жесткая связь.

Как вы могли заметить (надеюсь), есть другой способ достижения того же эффекта - использованиеnew оператор. Это еще один способ связать некоторый ваш код с конкретным именем класса.

No interfaces .. none .. whatsoever

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

Но, к сожалению, в центре внимания проблемы, вызванные отсутствием интерфейсов и существующей связью.

Один из компонентов, который разработчики попытаются заменить, - этоCUrlManager, В основном из-за того, как вы можете передать дополнительные параметры.

Интерфейс в ООП определяет контракт между двумя экземплярами. Это позволяет вам определить возможности экземпляра, методы, которые могут использоваться другими. Когда его нет, в большой кодовой базе вам остается угадывать, какие методы требуются, а какие нет.

В случае компонентов Yii проблема усугубляется еще больше из-за статического вызова и глубокого наследования. ВышеупомянутыйCUrlManager продолжаетсяCApplicationComponent, который расширяетCComponent, Также тот же файл определяетCUrlRule а такжеCBaseUrlRule классы.

Когда вы пишете замену, вы должны написать некоторый код, подключить его к конфигурации и затем протестировать, запустив ваши приложения. Таким образом, вы знаете, какой метод (или параметр) следующий вам нужно добавить.

В основном это"save-an-see-what-blows-up" способ разработки.

That's not MVC!

Yii не реализует MVC или любые шаблоны проектирования, основанные на MVC. То, что он называет "MVC" можно описать какActiveRecord-Template-Logic шаблон.

Вместо того, чтобы иметь надлежащий слой модели (да, это должен быть слой), создатель (и) Yii выбрал коллекциюактивная запись и сформируйте обертки. Это вызывает принудительную логику приложения в «контроллерах».

С другой стороны, у вас есть прославленные шаблоны вместо правильных экземпляров представления для содержания логики представления. Это несколько смягчается использованиемвиджетыно те вместо этого страдают отSRP нарушения, потому что виджеты вынуждены содержать биты логики представления и выполнять частичную визуализацию. Остальная логика представления снова попадает в контроллеры.

И что еще хуже, «контроллеры» также приходится иметь дело савторизация, Обычно это будет означать, что всякий раз, когда вы меняете схему доступа, вам придется проходить каждыйCController чтобы проверить, нужно ли это тоже менять.

Это не MVC. Это путаница с именами, взятыми из шаблона проектирования MVC и наложенными на некоторые компоненты.

All the small things ..

Фреймворк также поставляется с несколькими незначительными проблемами, которые не заслуживают отдельного раздела:

  • Defining more then one class per file:

    This will get annoying quite fast, because there will be classes that are shoehorned at the class files with completely unrelated filenames. This will mean, that debugging will quite often require use of search.

  • Slapped on "modules":

    By the looks of it, the modules where added to the framework after the fact. Which is why, when you need to set default module, you will have to set it in the configuration files parameter, that is called 'defaultController'.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededthis list.
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededIt is not MVC.Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded

Похожие вопросы