（中）
因为这次发表的内容比较多比较长，为方便大家阅读；我已分成三篇发文，大家要是有觉得有价值、感兴趣可以关注此账号或者加【PHP学习特邀群】获取完整内容以及更多内容。
12.2MB源码我也已经压缩打包好了进群你就可以下载，群是开放的。
目录（中）篇
输入和输出
路由模块
传统的MVC模式提倡为MCL模式
使用Vue作为视图
数据库 对象关系映射
服务容器模块
输入和输出
定义请求对象：包含所有的请求信息
定义响应对象：申明响应相关信息
框架中所有的异常输出和控制.器输出都是【 json 】格式，这在目前是很友善的，我们不需要再去考虑别的东西。
[ file : framework/ Request .php ]
[ file: framework/Response.php ]
路.由模块
通过用户访问的【url】信息，通过路.由规则执行目标控制器类的的成员方法。我在这里把路.由大致分成了四类：
微单体路.由
详细说下微单体路.由；面向 SOA 和 微.服务架构大行其道的今天，有很多的团队都在向 服务化 迈进，但是服务化过程中很多问题的复杂程度都是指数级的增长。
知识这难免导致小的团队从单体架构走向服务架构而艰难无比，于是就有人提出了微单体架构，就是在一个单体架构的SOA过程中把微服务中的的各个服务依旧以模块的方式放在同一个单体中，比如：
.
通过上面的方式我们就可以进行单体下各个模块的通信和依赖了。同时，业务的发展是难以预估的，未来当我们向SOA的架构迁移时，我们只需要把以往的模块独立成各个项目，再将App实例get方法的实现转变为RPC或者REST的策略就可以了，我们可以通过配置文件去调整对应的策略或者把自己的，第三方的实现注册进去即可。
传统路.由
.
【pathinfo】路.由
.
用户自定义路.由
.
如上，我们简单的在一个单体里构建了各个服务模块，还要在这些模块之间实现通信
如下：
.
[ file: framework/hanles/RouterHandle.php ]
传统的MVC模式提倡为MCL模式
传统的MVC模式包含【model-view-controller】层，绝大多时候我们会把业务逻辑写到【controller】层或【model】层，但是慢慢的我们会发现代码难以阅读、维护、扩展，所以我在这里增加了一个【logics】层。
这样看来，我们的最终结构是这样的
M:【models】职责只涉及数据模型相关操作
C: 【controllers】职责对外暴露资源，前后端分离架构下【controllers】其实就相当于【json】格式的视图
L: 【logics】职责灵活实现所有业务逻辑的地方
【 lo gics 】 逻辑层
逻辑层实现网关示例：
我们在【logics】层目录下增加了一个【gateway】目录，然后我们就可以灵活的在这个目录下编写逻辑了。【gateway】的结构如下：
.
网关入口类主要负责网关的初始化
代码如下：
.
实现完成这个【gateway】之后，应该如何在框架中去使用呢？
在【logic】层目录中我提供了一个【user-defined】的实体类，我们把【gateway】的入口类注册到【UserDefinedCase】这个类中
.
这样【gateway】就可以运作了。再来说说【UserDefinedCase】类；【UserDefinedCase】会在框架加载到路.由机制之前被执行，这样我们就可以灵活的实现一些自定义的处理了。这里的【gateway】只是个演示，你完全可以组织你自己的逻辑～
[ file: app/* ]
使用Vue作为视图
源码目录
完全的前后端分离，数据双向绑定，模块化等等。这里我把自己vue前端项目结构 【easy-vue】移植到了这个项目里，来作为视图层。我们把前端的源码文件都放在【frontend】目录里
详细如下：
.
build步骤
.
编译后
【build】成功之后会生成【dist】目录和入口文件【index.html在public】目录中。
.
[ file: frontend/* ]
数据库对象关系映射
数据库对象关系映射 ORM (Object Relation Map)
市面上对于 ORM 的具体实现有 TP 系列框架的 Active Record ； YII 系列框架的 Active Record； laravel 系列框架的 Eloquent ，那我们这里言简意赅就叫 ORM 了。
ORM 建模，首先是 ORM 客户端实体 DB ：通过配置文件初始化不同的 DB 策略，并封装了操作数据库的所有行为，最终我们通过 DB 实体直接操作数据库，这里的 DB 策略目前只实现了 my SQL 。
接着我们把 DB 实体的 SQL 解析功能独立成一个可复用的 SQL 解析器的 trait ，具体作用：把对象的链式操作解析成具体的 SQL 语句。
最后，建立我们的模型基类 model 直接继承 DB 。最后的结构如下：
.
DB类使用示例
.
Model 类使用示例
.
.
[ file: framework/orm/* ]
服务容器模块
什么是服务容器？
简单来说就是提供一个第三方的实体，我们把业务逻辑需要使用的类或实例注入到这个第三方实体类中，当需要获取类的实例时我们直接通过这个第三方实体类获取。
服务容器的意义？
其实不管设计模式还是实际编程的经验中，我们都强调“高内聚，低耦合”，我们做到高内聚的结果就是每个实体的作用都极度专一，于是就产生了各个作用不同的实体类。
在组织一个逻辑功能时，这些细化的实体之间就会不同程度的产生依赖关系。
在实现了一个服务容器之后，我把Request,Config等实例都以单例的方式注入到了服务容器中，当我们需要使用的时候从容器中获取即可：
.
[ fil e: framework/Container ]
完整内容请关注 [详解]从0开始构建一个属于你自己的PHP框.架（上） ——（下）以及【PHP特邀学习群】
.
.
