封装好的框架案例Git地址:
https://github.com/jiangshengxin/mvc.git     
git@github.com:jiangshengxin/mvc.git

----------------------------------------------------------------------------------------

首先,先来简单的说一下MVC.然后,直接说一下我封装框架的思路:
 1.M是指数据模型,V是指用户界面,C则是控制器。使用MVC 的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步,一旦M改变,V应该同步更新。
2.模型-视图-控制器(MVC),是一种软件设计模式,至今已被广泛使用.
3.MVC如何工做呢? MVC是一个设计模式,它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。

视图: 视图就是用户看到,并且与之交互的界面.在视图中其实没有真正的处理发生,作为视图来讲,它只是作为一种输出数据并允许用户操纵的方式。
模型: 模型表示企业数据和业务规则。在MVC的三个部件中,模型拥有最多的处理任务。被模型返回的数据是中立的,就是说模型与数据格式无关,这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。
控制器: 控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后再确定用哪个视图来显示返回的数据。

优点: 低耦合性, 高重用性和可适用性, 较低的生命周期成本, 快速的部署, 可维护性, 有利于软件工程化管理

好了,下面来说下我的框架封装思路,因为框架是在比较久之前封装的,而人是不断学习进步的. 所以,可能框架里面的部分功能并没有实现,因为当时对MVC的理解限制了我封装的局限性...
1. 这是框架的目录:
 
              |-- MVC   MVC框架目录
                  |-- appliction   项目目录
                  |   |-- controllers   控制器目录
                  |   |   |-- Index.php   这是控制器文件
                  |   |-- models   模型层目录
                  |   |   |-- IndexModel.php   这是模型文件
                  |   |-- views   视图层目录
                  |   |   |-- Index 这是Index控制器的视图层目录
                  |   |   |   |-- show.php   这是视图文件
                  |-- public   公共目录,用来存放js,css,image等等文件.
                  |-- config   程序配置和数据库配置目录
                  |-- runtime   临时数据目录
                  |-- logs   日志目录
                  |-- common   核心文件目录,存放框架核心文件,类库目录,函数目录,vendor目录
                  |   |-- function 自定义函数目录,这个目录里面的文件用来存放自定义函数文件,直接把函数文件拉进来,在配置文件里面配置加载即可
                  |   |-- library    类库目录,存放框架类文件,如数据库类,redis,memcached等等
                  |   |   |-- db 数据库操作类目录,里面是数据库操作类,类命名空间为: \library\db;其它类库也一样
                  |   |-- model    模型核心文件目录
                  |   |-- vendor   packagist目录,用来存放通过composer.json安装的类包
                  |   |-- Controller.php   控制器基类,所有的控制器类都需要继承这个类,用来加载一些控制器内用到的函数方法,初始化属性
                  |   |-- Model.php   模型基类,所有的model层都需要继承这个类,初始化model层属性
                  |   |-- Common.php   核心文件,被入口文件加载,整个框架的运行,路由的处理,检查环境,加载类文件,控制器,模型,视图,等等,所有的功能
                  |-- .htaccess   超文件入口文件,配置访问规则,访问不存在的目录/无权限访问的目录/文件等等,让其访问入口文件
                  |-- index.php   这是框架入口文件
                 

2.  好了,把框架整合设计完毕,就开始按照先前设计好的架构去实现它了:

1.inde.php入口文件, 这是用户访问的文件. 这个文件负责声明字符集编码, 定义框架路径, 加载框架配置, 核心类等等.

2.入口文件设计完毕,就开始加载框架的配置文件了,我把框架的配置定义在一个数组内,在config目录内的config.php文件完成配置参数的设置.如调试模式, 是否开启日志, 数据库配置, 缓存配置, 默认控制器, 默认方法, 404页面等等.

3.加载框架的核心文件,实例化核心类,将配置信息传入核心类

4.框架核心类, 获取框架的配置信息, 调用框架执行方法,开始执行程序

5.首先设置一个自动加载函数,如 __autoload 就可以实现类的自动加载.但是这里需要注意的是, __autoload 在php7.2被影响,所以最好不要用这个函数. 这样,我们可以用 sql_autonload_register 注册一个给定的函数为 __autoload 的实现,完成同样的功能...
设置尝试加载未定义的类完毕以后,我们可以继续设置框架的logs日志记录功能.这里,我设置了一个方法,用来获取框架的日志配置,在该方法内判断是否需要对框架的执行加入日志文件记录..
6.日志方法,判断是否存在 logs 日志目录,以及是否存在当天的日志记录文件,如2017_10_21.log ,这里我们用$logTmp来表示我们的日志保存路径 .之后我们开启这个文件的写入权限.然后我们用  error_reporting(E_ALL) 报告PHP的全部错误(这里的错误级别是可以改的), 之后 ini_set('display_errors','Off') 设置不满足我们之前规则的时候,将关闭这些错误, 之后 ini_set('log_errors','On') 开启日志的记录, ini_set('log_errors_max_len',1024) 设置每条日志的错误做大报告长度为1024 , ini_set('error_log',$logTmp) 设置日志路径,指定将产生的错误写入到指定的日志文件内...
7.接下来就是加载我们的报错方法了,报错方法决定是否将我们的错误输出,这里我用composer加载了一个非常不错的报错类库(下载类库请在composer.json文件中编辑内容 { "name": "php", "description": "php error", "type": "php", "keywords": [ "php", "php error" ], "require": { "php": ">=5.3.0", "filp/whoops": "*" } } 进行安装),如果配置设置调试默认,则加载我们的报错类库,用来报告我们的错误


 





























  
---------------------------------------------------------------------------------------------
唯有志存高远,方能风行天下。

道之所存,虽千万人吾往矣! 情之所钟,虽千万里吾念矣~

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。