TL; DR：不要这样做。这真是一个可怕的想法。
咆哮..
“框架”不是你添加到项目中的魔法酱，它可以让它变得更好、更闪亮。
做了一些研究，我发现 Yii 是目前最好的框架之一。
你做了多么奇怪的研究……我很想看看这些材料。特别是，因为我将它列为第三差的 PHP 框架。只有 CodeIgniter 和 CakePHP 超过了它的可怕性。
其原因是该框架显示的代码质量极差，再加上它一直存在的不良实践。
为什么要避免迁移？
从您的描述中可以明显看出，您不熟悉此框架，也没有使用过它的经验。
在项目管理中有一个主题：风险管理。在这种情况下，在项目的最后阶段添加一个以前未使用的框架将很可能构成高影响风险，而且由于项目的成熟度，这也是完全没有缓解的。
这意味着出现问题的可能性非常大。当它发生时，它很可能会导致项目失败。或者至少将发布数据推迟相当长的时间。
在完美世界中，框架用于简化开发的重复性任务，但会牺牲一些性能。这些是您在项目开始时执行的任务。你不是在一个项目的开始。这意味着您不会从这种“机动”中获得任何好处。
为什么不是伊？
正如我之前提到的，不仅有避免向现有项目添加框架的原因，还有避免使用 Yii 的原因。
遗产噩梦
你的所有控制器都将扩展类CController，扩展类CBaseController，扩展类CComponent
您所有的“模型”都将扩展 etherCActiveRecord或CFormModel, which extends CModel, which extends CComponent。
这两个链都包含静态变量并在许多不同的其他类上执行静态方法。这些因素的结合将使调试变得极其困难和乏味。
全局状态
有几种形式的全局状态。PHP 中的人通常知道的是global变量。但这不是唯一的形式。每次你有一个包含static变量的类时，它也会创建一个全局状态，它可以（并且几乎总是 - 将）导致看似不相关的实例神秘地交互。
使用全局状态是核心机制。你会在整个代码库中看到静态调用，如果没有全局状态，Yii 的配置文件将无法运行。
每次您打电话时，Yii::app()您都在访问和/或更改它。
这使得 Yii 应用程序无法进行单元测试。调试变成了grep在整个项目上使用的练习。
紧耦合
当你在 Yii 中创建应用程序时。它与它绑定。如果不启动完整的框架，您将无法执行应用程序的某些部分。主要是由于静态调用，您最终会添加到代码中。
每次您在自己的代码中添加静态调用时，这段代码都会与类的名称相关联。这本质上是紧耦合。
您可能已经注意到（希望如此），还有另一种方法可以达到相同的效果 - 使用new运算符。这是将您的某些代码耦合到类的特定名称的另一种方法。
没有接口..没有..任何
无论 Yii 项目的配置多么糟糕，配置文件都是一个善意的姿态。在如此混乱的代码库中引入外部代码和替换现有组件的危害最小的方法。
但不幸的是，它把焦点集中在了缺乏接口和现有耦合所带来的问题上。
开发人员将尝试替换的组件之一是CUrlManager. 主要是由于您如何传递其他参数。
OOP 中的接口指定两个实例之间的契约。它允许您定义实例的功能、其他人可以使用的方法。当它不存在时，在大型代码库中，您只能猜测哪些方法是必需的，哪些不是。
在 Yii 组件的情况下，由于静态调用和深度继承，问题更加复杂。上面提到的CUrlManagerextends CApplicationComponent，就是extends CComponent。同样的文件定义CUrlRule和CBaseUrlRule类。
当你写一个替代品时，你必须写一些代码，把它插入配置中，然后通过运行你的应用程序来测试它。这样您就知道接下来需要添加哪个方法（或参数）。
基本上，它是“save-an-see-what-blows-up”的开发方法。
那不是MVC！
Yii 没有实现 MVC 或任何受 MVC 启发的设计模式。它所谓的“MVC”可以描述为ActiveRecord-Template-Logic模式。
Yii 的创建者没有选择适当的模型层（是的，它应该是一个层），而是选择了活动记录的收集和表单包装器。这迫使应用程序逻辑被强制在“控制器”中。
另一方面，您拥有美化的模板，而不是包含表示逻辑的正确视图实例。使用小部件在一定程度上缓解了这种情况，但它们反而遭受SRP违规，因为小部件被迫包含一些表示逻辑并执行部分渲染。其余的表示逻辑再次在控制器中结束。
更糟糕的是，“控制者”还必须处理授权。这通常意味着，每当您更改访问方案时，您都必须检查每个实例CController以检查它是否也需要更改。
这不是 MVC。取自 MVC 设计模式并在某些组件上打上的名称是一团糟。
所有的小事情 ..
该框架还带有一些小问题，不值得单独的部分：