上一章 文档首页 下一章


5.3.1 术语表

我们并不想“制造”一些新的术语来增加大家的学习成本,但为了更高效地进行专业交流,我们将PhalApi框架中所用到的一些概念进行提炼并罗列如下。

(1)接口服务

通常,我们把远程第三方提供的接口称为API。但秉承Web Service的概念,我们更愿称接口为服务。为了同时保留这两者的意思,我们在这里统一将API称为 接口服务 。也就是我们对应的?service=XXX.XXX 。

(2)资源服务

在使用DI依赖注入进行注册的组件,我们也倾向称之为服务,同时也是一些服务端上可用的资源,如数据库、缓存、加解密等。因此统称为 资源服务

5.3.2 PHP开发建议

在实际项目开发过程中,通过观察不同开发人员编写的PHP代码,会很趣。因为你会发现每个人的编程风格都不尽相同,但我们更提倡约定编程、规范的代码和编写人容易理解的代码。所以,下面就发现的问题进行说明。

(1)滥用的静态方法

很多框架和很多项目都说自己在使用面向对象编程,但其实很多时候是在类中全部使用静态方法的伪面向对象。这里可能会引发争议,因为有些同学会认为静态类方法比成员函数更快速,而且也确实有相关的数据表明是快了一点点(严格上来讲,很微小)。但作为代价,我们失去的更多。如我们没能使用动态,也不方便在单元测试时使用桩、短件、模拟等技巧。更为重要的是,失去了高层的概念提炼和规约层的约定,不利于接口和实现地分离。

所以,请只有在需要的时候才使用静态static方法,如工具类或实用操作。

(2)非真正意义上的单元测试

很多时候,我看到很多框架和项目中没有单元测试的代码,就算有也不是真正意义上的单元测试。可测试的代码是美的,因为可测试的代码表明职责单一明了,有低耦合度,可以进行快速模拟和替换。关于单元测试,前面已有文档详细说明。

所以,请尽量尝试和坚持PHPUnit单元测试,体验测试驱动开发的乐趣,体验浮现式设计的激动。

(3)无处不在的单例模式

很多同学在学习了设计模式后,都很想试用一把,所以往往在很多时候是为了“用设计模式”而用设计模式,而不考虑是否合适,是否真的需要。尤其对于单例模式,这种情况更为普遍。

使用单例模式的时机包括有:提高系统性能、全局只能有且只有一个实例否则会导致问题发生、提供一个全局的公共访问点等。

然而其他很多情况则不需要。例如很多情况,实例为某容器所持有,则只需要在容器内做数量控制即可,不需要被持有的实例再作单例控制。

所以,请只有确切需要使用单例时才使用。

5.3.3 PhalApi框架的不足

在我们不断维护、演进PhalApi框架的同时,我们也在使用这个框架进行了很多项目的开发,与此同时也在阅读各方面的书籍以获得更深层次的理解。
在这样实践、思考、再设计的不断反馈迭代后,我们看到了PhalApi确实在某方面表现得出色。

但一个负责任的框架,应该也明确指出它的不足。
这里,我们将PhalApi开发中的不足罗列如下,希望为你进行框架设计或者对PhalApi的使用有更好的理解。

(1)接口结果中msg应该改名为error

我们推荐的接口返回格式为:

{
    "ret": 200,
    "data": {
        "code": 0,   //对操作码进行说明
        ....         //更多结果的说明
        "msg": ""
    },
    "msg": ""
}

显然,上面两个msg字段,会给开发团队带来困惑或混淆。
更好是应该把最外层的msg改成error更为贴切,因为只有错误时此字段才有效。

但基于前期的大量文档说明,此外层的ret、data、msg三个字段已约定。所以,只能从应用层的msg进行重命名,如tips。

(2)对NotORM中limit操作的错误优化

前期,由于没有深刻留意MySql中OFFSET关键字的作用,导致了做了一些不精确的优化。

可注意以下的微妙区别:

limit 5 OFFSET 10   #从第10个位置开始,查询前5个

limit 5, 10         #从第5个位置开始,查询前10个

但重点考虑到如果修复这个之前犯下的错误,会对项目升级后有很大的冲动。
可预料的故障有:”升级后,首页列表无任何数据显示“和“升级后,列表数据过多导致App加载崩溃”。

最后,出于对已在开发或已上线项目的保护和承诺向前兼容的原则,我们不得不保留了这个污点。
所以,当对底层进行改动时,须确保已透彻理解各操作的微妙区别。

(3)对数据库操作封装的欠缺

一直以来,数据库支持这块都是比较欠缺的。所以我们使用了NotORM。

但我们为了能更好把NotORM与PhalApi整合,将它调整成更适合我们的使用方式,我们又为NotORM提供了一个封装层,类似代理。

然而,这会为新手入门这个框架造成一定的迷惑。
因为,这有两套操作数据库的区别。但他们一开始不能很好地理解这样的区别,以及这样设计的初衷。

坦白来说,PhalApi对于数据库这块不是好的设计,但好在它可以使用并正常地工作。


上一章 文档首页 下一章

还有疑问?欢迎到社区提问!    切换到PhalApi 2.x 开发文档。

Fork me on GitHub