文件型Restful方案 for PHP 小记

GITHUB链接:https://github.com/watert/FRestJSON

文件存储,也叫嵌入式存储,就是指代码和数据放在同一个工程目录下,一起通过文件管理。

后台开发的童鞋们可是恨死了这种方式了——他们玩的就是存储和计算,文件型存储方案通常就意味着很多缺点:

  1. 工程管理粗暴,数据没法分离化管理
  2. 没法针对数据结构做良好的计算设计,意味着性能低下
  3. 没法通过统一手段进行数据维护,比如各种分片、分布式神马的
    也因此,版本管理时还容易出现数据丢失神马的状况……因为,没了DBMS作为中间层,不可能专业

所以SQLite神马的还真是不太受待见,相反在手机、浏览器之间发扬光大:闪谁了小量存储也不是不行滴。

但最近前端盛行之后,终于开始越来越多这类的轻量级方案了。

大概是因为众前端终于认清一个问题:我不就做个CRUD,凭什么非得写一堆SCHEMA和SQL,还有极其麻烦的部署操作等等?

文件型方案除了在小量存储领域,其实还在另两个方面也很有用:原型开发或是内网开发领域。

这不刚好把我的兴趣和工作都覆盖了么!真™一举两得呐。

在这样的范畴,之前一直挺尴尬的:

  • 一方面,过早的引入数据库,往往就意味着过度设计;
  • 另一方面,如果完全不提供持久化,则会严重影响产品初期体验的效果。

与其把精力花在后端的存储层面,前端、界面及交互这些方面对于情感化传达与讨论其实是更立竿见影的。live streaming movie Born in Chinawatch movie Boyka: Undisputed IV 2016 now

Nodejs上倒是已经有了先行者,好像叫emdb,实现得还很不错。可惜我所在的环境似乎还是用PHP用得更多,Nodejs没多少人把之看成标准的WEB开发手段,而更是当作工具来实现一些HACK。所以,我需要整一个PHP版本的,而且要符合我的编程习惯:能支持得上Backbonejs的RESTful接口的一个嵌入式存储方案。

实现过程

基于Model的实现非常容易,我只要把基本的增删改查做好就是,接口也很简单:因为URL是统一的。

但开始往Collection操作支持时却出现了点问题:RESTful对于列表中的条目定位用的是id,这个id是直接跟在url后面作为QUERY前面的部分,参数则放在QUERYSTRING中。

所以,我就只能破坏我原本的“单文件”的思路,从而不需要在使用的时候在Backbone上做一些hack。

代码加起来就写了200+行,预计之后完善各类问题之后也不会超过500行。整个工程除了测试用例之外,就只剩两个文件:.htaccessfile_rest.php。后续也许可以考虑使用 .filerest.php这类的名称,使整个文件夹更加的纯粹。

后续还要实现基本的过滤与排序的功能,这很烦,其实我知道有很好的解决方案,就是使用underscore的PHP port,各类的操作都很方便,而且符合我前端的编程习惯。烦就烦在,在公司我用的更多是PHP 5.2……对于各类迭代方式尤其是以匿名函数为基础的操作都实在逊爆了。我就想说卧槽尼玛了。唉,又得写多很多代码。

小结

Github真是个好东西,主要是有些基础的东西可以沉淀下来,不至于代码放得到处都是,稍重的可以用repo,轻的也可以用gist。而且,看着自己的commit年度记录,一片绿油油的话还是很爽的。

工作上其实很多设计都很简单直接,直接到了基本上就是针对某个页面的一个配置而已,而这类东西如果要通过数据库的方式来实现,成本真会很高。

Restful的方案对于前端来说,简直就是万金油呐。

先这样慢悠悠地维护着吧,有兴趣的童鞋也可以来提issue啥的 :D

One Reply to “文件型Restful方案 for PHP 小记”

Leave a Reply

Your email address will not be published. Required fields are marked *