设计思想中有两种极端：大而全、小而美。

一般我们常用的库是小而美，用的框架是大而全。从Symfony实现Component式开发开始，框架的组件化逐渐成为趋势。我们可以任意的组合各种Compoent来形成自己的PHP框架，比如B团队出的Db及ORM引擎、B团队出的缓存引擎、E团队出的Route映射引擎、C团队出的DI、D团队出的MVC、X团队的单元测试工具。Composer出现后，提供了高度便捷性，加速了这种趋势。

Yii这个框架是典型的全栈式框架，常规应用开发所需功能几乎都揉和到一个项目中。yii2到现在，它的核心实现还是以传统Web应用场景为重心。但这只是他的形，他的核心思想里是组件化的，有Component这样的完善机制，只是没有拆开成各个子项目而已。

如何将Yii2这样的项目拆成Component式的子项目呢，你可以自己想想！

代码重用据说是OOP思想最想要解决的问题？如果我们写出的每个功能，抽象的库、具体的业务模块，都可以实现最大化独立和重用，似乎是很美好的一件事情，借助于开源的趋势，若干年的积累后，只要像搭积木一样组合一下，就可以完成满足实际需求的应用系统。

请注意上文中的“搭积木”这个词，搭积木源自于孩童时的游戏，不同的积木组合可以拼成各种房子、各种车等，但积木组合出来的都是人所处环境的实物，和应用系统这种存在于计算机世界的事物在目前的认知上是完全不同的体系，搭积木这个词用在应用开发上，合适吗？

通常我们的结论是这样：代码可以以库的形式重用，重复的功能模块式开发和引用，但不同的应用有不同的场景，还是需要以比较“巧妙”的方式去定制的，比如“钩子”、“行为”、“事件”、“插件”等。

话再说回来，组件化可以到什么程度呢？

市面上成功的CMS等系统都通过“插件”或“扩展”，配合“应用市场”建立了比较强大的开发者生态圈，通过“巧妙”的机制实现具体场景的定制化，满足用户的需求。

举个简单的例子来说，TP的Model是这样的：

在具体的Model里如UserModel，覆盖

// 删除数据前的回调方法
    protected function _before_delete($options) {}
    // 删除成功后的回调方法
    protected function _after_delete($data,$options) {}

这两个方法以实现数据删除前和删除后触发的关联操作，但Yii中，只要继承Component基类实现的类，都可以使用事件和行为来扩展原来的逻辑，而且可从外部来定义，非常灵活。

yii中的用法大致为：

$model = new User;

$model->on(‘before_delete’, $callabe, $data);

TP的控制器中也有钩子，应该也算是一种实现方式吧。

库Component化、业务功能以模块化的方式实现，就可以实现扩展和定制的无限可能性。