如果一个框架能用很少的业务代码实现特别多的功能，那么其实就是这个框架内置了大量的惯例，当这些惯例不符合项目预期的时候，如何添加代码精确地改变对应的惯例，而不搞砸其他部分，就会变的很难。经典的例子是各类CMF，drupal， wordpress，比起框架来已经更接近应用了。
如果一个框架能实现的功能很多，也很容易修改或定义其中的功能细节，那么这个框架往往需要写非常多的业务代码来填充起这些允许自定义的部分（因为如果这些部分有预设值，这个框架就落回到上一个类型）。一般而言的“重”框架往往是这种类型。
而一个框架如果要写的业务代码不多，也还是能够轻松的改变其中的功能，那么这个框架往往无法内置很多功能，需要开发者自己动手拼积木。
以上是我总结的框架的三角原理，业务代码（少），内置功能（多）和内部掌控（易）三者不可得兼。
作为开发者，我选择放弃内置功能的数量，因为我觉得这是唯一可以由外部弥补的，不属于一个框架本身素质。
啰嗦了这么多，这是一个以PSR为核心的，自带DI机制的微框架，其他一切皆可选配。如果你喜欢Slim，但又嫌弃他自身不模块化没法换轮子，DI不正宗搞service locator反模式，不妨了解一下。如果你还不了解Slim，还不知道为啥那么多老司机上手就是Slim，但又懒得四处安利Slim这么小的框架究竟好在哪里，那也可以和Slim一起看下。
http://litphp.github.io/blog/... (全英文预警)
以上所述就是小编给大家介绍的《虽然并没有贡献者出现，但我还是坚持把我的PHP框架堆到完成度很高的程度了》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 开源社区贡献者协议介绍
- SegmentFault 年终盘点 - 2017 优秀贡献者
- 中国软件业正成为开源生态贡献者
- 谷歌是 CNCF 开源项目最大贡献者，红帽次之
- 谷歌是 CNCF 开源项目最大贡献者，红帽次之
- PgSQL 主要贡献者对 PostgreSQL 内置分片功能的看法
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
