扫一扫浏览

透析thinkphp5升级版开发框架tpframe

未结贴

 3  6239

鸿老大站长未认证 2018-03-28 16:52:31

这里将全面的介绍这个框架给我们开发带来的好处，让你们对它有更深层次的认识，喜欢或不喜欢的，欢迎大家前来留言讨论

一、目录层次结构

现在很多的项目，特别是大一点的项目里面，都会有很多的人参与，要进行程序查询找、修改或是升级扩展的时候，目录结构一目了然就显得很重要了，更重要的是后面的人来接手的话，目录结构不清楚，程序结构很乱的话，那估计接手的人只有哭了

下面就是tpframe的框架目录结构，是不是很干净

每个目录结构：

addon：插件目录

application：应该模块目录

coreframe：核心程序目录

data：运行时目录（缓存、上传文件等）

extend：扩展目录（保留），为了保持tp5程序扩展的风格，如果你习惯tp5的开发风格，你也可以在这里面扩展

theme：模板目录（前台、后台）

是不是很一目了然，各个功能模块都很清楚分开存放呀

二、程序分层结构

分层并不是tpframe弄出来的，而是把tp5的分层给充分利用起来，当然我这里不是说的程序框架模式，经典的还属MVC，那当然还有其它模式，像MVP,MVVM,CBD，ORM等等

我这里要说的是MVC更细化分层，每层的在功能设计中所起的作用，为什么要这样设计等问题

我也看到过CV模式，有部分人就推崇这种简单直接的模式，其实这种就相当于原生PHP再升级一下而已，把逻辑相关独立出去，当然我想的是他们喜欢这种的目的就是觉得简单，直接了当，有人说程序执行更快？加载的东西少？

哈哈，如果仅仅是为了速度问题，原生比什么框架都快，不是吗。所以讨论到这个问题你就输了（别太认真），一个框架好与不好，个人觉得应该从如下方面来参考

？可读性好不好（换一个人能不能快速的入手）

？可维护性好不好

？程序可扩展性好不好

？程序之间耦合度是否达到尽可能的低

？重复代码是否将到最低

......

说了这些我就会问，原生PHP能做到上面的某些方面么，就拿CV模式来说，如果一个逻辑代码成千上万行了，改起来估计难度很大吧，动不动出错了怎么办，要在中间加一块功能，换一个人估计都不敢改了。

那么TPFrame框架的分层结构是怎么样的呢？我先来说一个公司的事务处理流程

首先是公司的前台人员，如果有外来人员（浏览器）,简单的事情（不进行数据处理）直接回复就可以，如果要设计到公司重要的事情，她们便把事情通报给相应的部门（对应的部门，为客户服务的）来处理，每个部门处理重要事情总得要领导决策的吧（最终数据处理），然后再原路返回，再由前台人员把反馈结果给外来人员（浏览器），所以就得到了如下分层结构

1）、controller：控制层，控制转发，相当于前台

2）、service：服务层，为数据处理而服务器，出问题，回滚，数据拦截，验证等，相当于各部门

3）、logic：逻辑层,数据处理层（CURD操作），相当于领导

4）、view：视图层，这便是最张呈现给客户的方案

当然为了数据的更细化，规范化，还少不了其它的层

5）、model：模型层，数据自动处理（数据自动完成、数据修改），其实真正的数据处理层就是它

6）、validate：验证层，数据在进行CURD之前的验证操作可交给它

你们可去看thinkphp文档，这些层都是有的，只是它介绍的不是那么的详细。

当然有人说了，这样开发起来好复杂哦，当然，对于一些最终都是很简单的项目，可以认为它是有点复杂的，但对于一个长期项目，以后要扩展，升级，维护的项目，这种分层绝对是有必要的。当然这样分层也减少了代码之间的耦合度。

三、程序代码结构

现在的很多项目需求都是各端都要求（app\mobile\pc），而在开发的时候，分三批人分别开发也好，一批人按计划开发也好，写好一套再写一套，还是各写各的一套。。。我们都知道，不管是app也好，mobile或pc，一个项目，他们的展示数据大部分都是相同的，也就是说他们对数据处理的大部分功能都是相同的，倘若是分开写的话，就会有大量的代码重复，以后升级三端都是加，改也要全改，维护起来更是老火。

那么针对这种tpframe给出来的解决方案（建议）：

1）、逻辑共用（放公共模块），当然除非你肯定这个功能只有这个模块要使用，你就可以写在当前模块里面

2）、服务层各模块，因为模块（部门）对数据的处理可能不一样（领导下达的任务），例如app可能要规范一定的数据，返回数据为json格式，而pc则不一样

3）、控制器各模板，因为不同端的入口可能不一样

这里主要在逻辑层，因为它是最重要的，也是处理比较频繁的，它共用后，以后维护，升级都方便了。