框架总结：术语表和PHP开发建议.pdfVIP

框架总结：术语表和PHP开发建议 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 、 ata、msg三个字段已约定。所以，只能 从应⽤层的msg进 重命名，如tips 。 (2)对NotORM中limit操作的错误优化 前期，由于没有深刻留意MySql 中OFFSET关键字的作⽤，导致了做了⼀些不精确的优 化。 可注意以下的微妙区别： limit 5 OFFSET 10 #从第10个位置开始，查询前5个 limit 5, 10 #从第5个位置开始，查询前10个 但重点考虑到如果修复这个之前犯下的错误，会对项⽬升级后有很⼤的冲动。 可预料的故障有：”升级后，⾸页列表⽆任何数据显⽰“和“升级后，列表数据过多导致 App加载崩溃” 。 最后，出于对已在开发或已上线项⽬的保护和承诺向前兼容的原则，我们不得不保留 了这个污点。 所以，当对底层进 改动时，须确保已透彻理