McFog＠がんばらない

LitPHP(官网 | Repo) 昨天正式开源了，这是喜欢框架的我的第一个自认为能拿出手的作品。终于有了这么个作品让我相当地感想万千。先贴上12个类+1个接口的类图

LitPHP的设计哲学

• 让程序员选择 @Backbone

  • 在Backbone官网中，找到这样一段话

    Backbone.js aims to provide the common foundation that data-rich web applications with ambitious interfaces require — while very deliberately avoiding painting you into a corner by making any decisions that you’re better equipped to make yourself.

  • 我太喜欢『paint into corner』这样的说法了，这是我用很多其他框架的直观感受，可以翻成『画地为牢』吧，我把这段话翻译一下套到LitPHP上来

    LitPHP希望提供一个性质良好的PHP程序结构。为了避免画地为牢，LitPHP刻意减少功能，不作任何我们认为应当由实际开发者来做出的决策（比如视图层究竟包含哪些职责/如何嵌套，又比如ORM或模板引擎的选择）

  • 为什么选择LitPHP？因为它让你选择！

• 『中间件』及其支点 @connect

  • connect作为一个非常成功的框架，其中间件的理念让nodejs在webserver方面的成就拔高了一截。

  • 中间件(middleware)模式和插件(plugin)模式的区别，在我看来可以理解成插件是『改变原有功能』而中间件是『拼接出需要的功能』。插件主要『覆盖』而中间件主要『连接』。

  • 中间件为了达成连接的目的，需要不动的支点，nodejs天然提供了request对象和response对象，connect的中间件便以这两个对象为支点，通过这两个对象来协作。

  • LitPHP中，Route相关代码扮演connect的角色，让中间件得以执行，而其他代码就聚焦于扮演支点的角色：Lit_Result大约是response的角色，而看似突兀又简陋的Lit_Http_Conversation，其实扮演了非常重要的request的角色。Lit_App作为全局工厂，让动态程度不及JS的PHP能够更好的改变/添加各个组件的功能，还提供了context作为全局黑板便于信息交换。

    虽然尚未经过实践，但我可以想象负责缓存的中间件在判断缓存命中后，设置一个Cache_Hit_Result后中断后续路由逻辑；负责用户登录的中间件在发现用户未登录时设置跳转Result并中断，否则将用户信息写入app context……

• 无招胜有招

  • LitPHP基本没有::符号写死类名，也不存在final的方法，而每个方法都不超过10行代码，你可以而且很容易通过继承来控制所有行为。
  • LitPHP没有刻板的MVC划分。只要有接受Lit_App的callback，就可以作为C；只要继承Lit_Result，或与其组合，就可以作为V；只要不是V，就可以视为M。实际应用中如何分层如何配合，完全由使用者自己决定。

最后贴上QQ群__341338880__，欢迎加群讨论