Migrating pure PHP project to Yii framework

Question

I have almost completed a PHP project, using MVC, jQuery and Ajax. It is pure PHP project. I don't use any frameworks in the code right know. I would like to change that. Doing some research, I found, that Yii turns out to be one of the best frameworks out there.

Is it possible to somehow migrate pure PHP project to Yii?

If so, then how to do this? Which steps should I follow in order to reduce the workload and enjoy the benefits the Yii framework presents?

I'm a total Yii newbie, any insights appreciated.

Answer 1

TL;DR : Don't do it. It's a really horrible idea.

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.

What a strange research you have done .. I would love to see the materials. Especially, since I would rank it as 3rd worst PHP framework. Only surpassed in it's awfulness by CodeIgniter and CakePHP.

And the reason for it is the extremely bad quality of code, that this framework displays, combined with the bad practices, that it perpetuates.

Why avoid migration?

From your description is obvious, that you are NOT familiar with this framework and have no previous experience with it.

In management of projects there a subject: risk management. And in this case, adding a previously unused framework in final stages of project would constitute a high probability an high impact risk which also, due to the sage of project, is completely unmitigated.

It means that there is a really good chance that something will go wrong. And when it does, it most likely will sink the project. Or at least push back the release data by significant length of time.

In a perfect world frameworks are used to simplify the repetitive tasks of development, at the cost of some performance. Those are the tasks you do at the start of the project. You are not at the start of a project. This means that you will gain no benefits from this "maneuver".

Why not Yii?

As I noted before, there are also reasons not only for avoiding adding framework to an existing project, but also reasons why to avoid Yii in particular.

The inheritance nightmare

All your controller will extend class CController, which extends CBaseController, which extends CComponent

All your "models" will extend ether CActiveRecord or CFormModel, which extends CModel, which extends CComponent.

Both of there chains contain static variables and execute static methods on multitude of different other classes. Combination of these factors will make debugging extremely difficult and tedious.

Global state

There are several forms of global state. One that people in PHP usually know are global variables. But that is not the only form. Every time you have a class that contains a static variable, it also creates a global state, that can (and almost always - will) cause seemingly unrelated instance mysteriously interact.

Use of global state is a core mechanic. You will see static calls all over the codebase, and the Yii's configuration file would not function without global state.

And every time you call Yii::app() you are accessing and/or changing it.

This makes unittesting impossible for Yii applications. And debugging turns into exercise of using grep on your whole project.

Tight coupling

When you create an application in Yii. It becomes bound to it. You cannot execute parts of your application without launching the full framework. Mostly it is due to the static call, that you end up adding to your code.

Every time you add a static call in your own code, that piece of code becomes tied to the name of the class. That essentially is tight coupling.

As you might have noticed (hopefully), there is another way how to achieve the same effect - the use of new operator. That is another way of coupling some code of yours to a specific name of a class.

No interfaces .. none .. whatsoever

No matter how horrible the configuration of a Yii project is, the configuration file was a well intended gesture. The least harmful way to introduce external code and replace existing components in so messed up codebase.

But unfortunately it brings in the focus the problems caused by lack of interfaces and the existing coupling.

One of the component that developers will try to replace is the CUrlManager. Mostly due to way how you can pass additional parameters.

An interface in OOP specifies the contract between two instances. It lets you define the capabilities of an instance, the methods that can be used by others. When it's not there, in a large codebase, you are left guessing, which methods are required and which are not.

In case of Yii components the problem is compounded even further due to static call and deep inheritance. The above mentioned CUrlManager extends CApplicationComponent, which extends CComponent. Also the same file defines CUrlRule and CBaseUrlRule classes.

When you are writing a replacement, you have to write some code, plug it in the configuration and then test it by running your applications. That way you know which method (or parameter) next you need to add.

Basically, it's the "save-an-see-what-blows-up" method of development.

That's not MVC!

Yii does not implement MVC or any of MVC-inspired design patterns. What it calls "MVC" could be described as ActiveRecord-Template-Logic pattern.

Instead of having proper model layer (yes, it should be a layer), the creator(s) of Yii opted for collection of active record and form wrappers. This forces the application logic to be forced in the "controllers".

On the other hand you have glorified templates, instead of proper view instances for containing presentation logic. It is somewhat mitigated by use of widgets, but those instead suffer from SRP violations, because widgets are forced to contain bits of presentation logic and perform partial rendering. The rest of presentation logic ends up again in the controllers.

And to make it all worse, the "controllers" also have to deal with authorization. This usually will mean, that whenever you change the access scheme, you will have to go through every single instance of CController to check whether it needs to be changed too.

It's not MVC. It's a mess with names taken from MVC design pattern and slapped on some components.

All the small things ..

The framework also comes with few minor issue, that do not deserve a separate section:

• 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'.

Answer 2

I actually recently converted a MVC pattern website I had built from the ground up into Yii. It did take some time to set it all up but in all honesty it was well worth it. I was able to throw away a lot of code because there were already Yii extensions doing what I needed. I would also suggest that you keep your database because you can create the controllers and Models using Gii which will save you a ton of time.

Answer 3

I don't know of any quick solutions to this. It depends upon how the code was written. You have the database and your views so it is not really a complete new project when you take into yii. Yii will generate the database models for you. You already have the views from the existing project. Write the controller and actions and modify the views if necessary.

try these links as they refer to the same problem.

How do you convert an old oop project into Yii

tips on migrating an existing site to Yii

Drupal to Yii Migration