git reflog --pretty=format:"%ai,%an:%s" >log.txt

• 前提：我们要按照OOP的**封装MVC框架，因为主流的的编程**就是OOP（面向对象），那么我们的框架中，最小的单位就是类
• 如何使用OOP封装模型层呢？ 一张表-------->看做是一个整体------>类 表的操作（增删改查）------->看做是类的方法
• 在模型里面要想操作数据库，需要使用我们之前封装过DAOPDO类实现，所以我们在模型中实例化DAOPDO类：
• 将来不只是增加用户时需要使用PDO类，删除用户、修改用户、查询用户都需要使用DAOPDO这个类，所以我们就可以将公共的代码封装到构造方法中：

• 上面的代码还有问题：将来项目会有很多模型类，每个模型类都需要使用DAOPDO类对数据库进行操作，所以我们就将公共的代码提取到一个基础类中，其他类再从这里继承
• 哪个模型类需要使用这个公共的代码，再从基础模型类中继承即可

• 接下来我们要想调用模型的模仿，需要先实例化模型对象，之前说过：模型对象只需要实例化一个就够了，之前采用的是三私一公的方式，实例化一个单例对象，这样需要在每个模型类里面都得定义3个私有、1个公共的方法，这种写法比较繁琐
• 接下来我们采用工厂模式去实例化一个单例对象，工厂模式在我们这里指的就是，传递模型类进来，我给你生产模型对象出去
• 我们需要将数组定义为静态的变量，这样，在脚本周期内会将数组的值保存到内存中

• 控制器层是根据功能模块划分的，为什么按照功能模型进行划分呢？
• 如果按照功能模块进行划分，便于分工协作开发，一个员工负责一个功能，功能又是一个控制器类；
• 所以这个员工只需要负责一个控制器即可 功能模块是在项目分析阶段就决定的；
• 也就是说，这个项目包括哪些功能，在分析项目时就决定了。
• 既然按照功能模块进行划分的，那么每个功能模块里面的操作（例如分类的管理：分类列表、添加分类、删除分类、修改分类）封装到控制器的方法中
• 说明：控制器的方法后面加上Action后缀，目的是为了避免和模型类里面的方法名重复，方便记忆
• 通常我们在控制器类里面发布命令：命令模型处理数据、命令视图显示数据

• 将来项目会有很多功能模块，每个功能模块又是一个控制器类，每个控制器中都需要使用smarty进行数据的分配，所以我们将smarty的初始化再次封装到一个基础的控制器类中，其他的控制器再继承
• 所有的控制器类都需要继承该基础控制器类

• 将来使用mvc框架的时候，有一些代码是和具体项目的业务相关的；
• 所以我们将这些代码封装到项目的目录里面，通常取名为application，
• 该名称可以自己修改（jd、taobao）；
• 除此之外，还有一些代码是公共的（Controller.class.php，Model.class.php等等）；
• 这些代码不管做什么项目都可能会用到，我们就将其封装刀片框架目录里面；
• 取名为framework

• 由于随着框架的不断完善，里面会出现很多有用的工具类；
• 所以为了有效的管理，我们分目录存储
• 像smarty这样别人提供，我们就封装到vendor目录，表示别人赞助的
• 像Captcha、Page等等，我们自己写的，一些工具，我们就保存到tools目录
• 像DAOPDO、I_DAO这些类、接口，和数据访问相关的，保存到dao目录

• 由于应用程序（项目），分为前台、后台；（前后台功能不同/页面不同，因此将前后台代码/逻辑分离开来，创建为独立的模块--模块化）
• 前台是用户浏览使用的；
• 后台是管理员进行内容管理的；
• 所以我们项目的目录结构也就划分为前台home、后台admin：
• 由于前台、后台为了提高开发效率，也都会使用mvc进行代码的管理

• 入口文件又称之为分发控制器；
• 就像公司的前台，根据访客的需求，将其引导到对应的办公室。
• 在我们的框架里面，入口文件会根据用户的需求，引导到对应的文件
• 那么我们需要在入口文件传递什么参数呢？也就是需要告诉前台哪些信息呢？
  • 去前台还是后台？admin?home
  • 去哪个控制器？controller?
  • 访问控制器的哪个方法？

• 项目中还有很多类需要require加载，这是一个很庞大的工作，而且很繁琐;
• 所以我们使用自动加载机制完成这个工作
• 当我们使用一个类，但是这个类不存在时，就会触发自动加载机制，自动加载机制提供了最后一次机会，可以把类加载过来
• New 类，不存在
• 类：：静态方法时，类不存在
• 类 extends 类2，类2不存在
• 类 implements 接口，接口不存在

• 入口文件就不用加命名空间了。因为入口文件用来加载其他类，不定义类
• 每个类的命名空间包含当前类所在的路径 例如：框架的成员，命名空间定义为：framework\core，项目的类命名空间就不要携带application了，因为application是项目的名称，后期可能会变化，所以项目的类的命名空间：admin\controller或home\controller等
• 第三方的类，我们不用增加命名空间，我们做一个特例处理（手动require）

• 就是根据提示的需要的类名，解析出他所在的路径

• 入口文件有什么好封装的呢？
• 因为我们采用的OOP（面向对象的**）封装的框架，框架里面的代码都应该是类，然而现在的入口文件index.php是完全面向过程的写法，所以我们要将其封装到类中

说明: 配置系统是什么？

• 框架的配置文件
• 公共的配置文件（例如前后台公用的配置文件）
• 应用的配置文件

配置文件就是用来保存一些有固定格式、多文件之间的公共的数据 我们在学习smarty的时候，使用过配置文件来保存图片的信息，这样，如果将来图片的路径变化了，我们只需修改配置文件即可，从而提升了维护的效率 我们的mvc框架中，怎么增加配置文件呢？

框架应该有自己的基本的信息，例如，框架的版本、模板引擎的模板目录、定界符等将来都可能修改，所以框架应该有自己的配置文件

我们的应用程序也会有一些将来可能修改的数据：数据库的信息，所以应用程序也应该有自己的配置文件

为了灵活起见，我们给前台、后台也增加一些配置文件，目前可能用不到，但是将来可能会用到，所以我们未雨绸缪 如果同时存在3个配置文件，

框架的配置 < 公共的配置 < 前台、后台各自的配置 具体实现： 先创建各自的配置文件： 如何实现优先级高的 覆盖优先级低的配置文件中的相同的配置项，还有一点需要注意：不相同配置项要合并 既然配置文件返回的是数组，那么我就使用数组函数：array_merge()合并数组的 有这样一个机制：相同的会被覆盖、不相同的合并

array_merge() 将一个或多个数组的单元合并起来，一个数组中的值附加在前一个数组的后面。返回作为结果的数组。 如果输入的数组中有相同的字符串键名，则该键名后面的值将覆盖前一个值。然而，如果数组包含数字键名，后面的值将不会覆盖原来的值，而是附加到后面。如果只给了一个数组并且该数组是数字索引的，则键名会以连续方式重新索引。

思考：mvc框架中如何实现，配置文件的整合 （1） 代码在哪里写 （2） 再考虑怎么写

首先，在Framework.class.php中增加3个方法，加载配置文件 因为该文件就相当于入口文件，在这里定义之后，可以在任何地方使用 拿到配置文件的信息之后，替换、合并 （3） 具体应用配置文件： 在初始化MCA的时候，需要设置默认的模块、控制器、方法

数据库连接部分使用我们配置文件中的配置项进行维护、管理 数据库的连接、初始化是在Model.class.php基础模型类中初始化的

路径常量  说明: 路径常量是什么？ 框架中，有一些涉及到路径的地方，我们写死的，例如： 如果项目名称后期改变了，我们就需要找到smarty的配置初始化的代码进行修改，我们就可以将项目的名称、路径保存到常量中 将使用到项目、框架的路径部分，使用常量代替：

我们要将模型中经常使用到的sql语句公共部分再起提取出来，封装到一个方法中。例如：下面的sql语句我们就可以简化为：

$sql = "insert into table (id,name) values(1,2)"
$data = [
    'id'=>$id,
    'name'=>$name
];
$this->insert($data);

因为一个模型对应一个表，在模型里面定义方法，属性，来完成该数据表的增删改查操作 模型的目的就是将一个项目的很多个数据表抽象成我们可以更加直观看到的类，通过对该类的封装，操作，来对对应的数据表进行增删改查。因此，模型使得项目逻辑更加清晰，模块化鲜明，让开发人员开发起来更加方便。 可以思考如果没有模型的话，我们对所有数据库的操作都需要写相应的增删该查方法，sql语句，这无疑增加了代码量，也使得项目变得可读性没那么高。因此，模型其实也是将sql语句中重复的部分的封装，减少了代码量，同时使项目更具可读性，其他人员也能较快速的阅读代码，因此维护、项目交接等等也变得相对轻松了。 6.2 自动插入数据  介绍: 就是将插入数据的公共的代码：INSERT INTO 表名(字段) VALUES(值) 最终封装结果是：insert(array(‘字段名’=>’字段值’)) 由于该方法不仅在商品模型中使用，在其他模型中也可能会使用到，所以我们将其封装到Model.class.php这个基础模型中

 补充： 由于我们在设计模型类的时候，原则：一张表对应一个模型类，所以我们就给每个模型类增加属性：logic_table保存该模型操作的数据表 又由于我们的模型继承了基础模型类，那么基础模型类的构造方法也会被继承过去，所以我们给就可以在基础模型中使用logic_table属性