我的书签
添加书签
移除书签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对于数据库这块不是好的设计，但好在它可以使用并正常地工作。
