match_model
模型层典型实现
典型的MVC框架中，模型层代码组织结构是什么样的！
模型类
每张表，对应一个操作模型，当前表中的所有操作，都是用该模型完成！
[模型类]每张表的操作模型，由某个模型类实例化而来的对象【语法】。
每个表操作，对应模型对象的一个方法。
模型类的示例代码：
同时修改控制器中，使用模型的方法：
C：
Tip：模型，在项目中，通常指的是模型类的对象，而不是模型类本身。
基础模型类
显而易见，在模型中，可能会出现重用的代码，例如（得到DAO对象过程），而且是每个模型对象的每个方法中都需要！
被其他的具体模型类所继承：
MatchModel
基础模型类中增加，初始化数据库操作对象的功能：
Model.class.php
将实例化好的MYSQLDB类的对象，存储到模型对象的属性上，从而保证，模型类的每个方法中都可以使用该属性。
模型方法中的使用：
MatchModel->getList();
何时调用该初始化DAO的方法？
在实例化模型类对象时，就需要操作数据库，就需要执行初始化DAO的方法。
可见在构造方法中被调用即可：
Model.class.php
此时的模型结构关系：
模型的单例
如果在一个功能（控制器）中，如果使用某个表的多次操作，应该使用该表的一个模型就可以完成全部任务。
如何保证模型的单例？
典型的，可以通过一个单例工厂来实现（为什么不三私一公？是多个（所有的模型类）都需要单例效果）
工厂类：
直接new，不能实现需要的业务逻辑，需要辅助一段代码逻辑代码，才能确定如何去实例化对象，此时需要工厂类。
模型对象的单例效果：
不能在需要模型时直接就实例化，因为不能实现单例效果，需要一段逻辑代码，来判断当前模型类是否已经实例化过，如果实例化过，则直接返回实例化过的对象，否则实例化新的。
代码实现：
增加工厂类：
Factory.class.php
控制器中，为了得到单例对象，则需要通过工厂类的M方法完成：
模型的流程
5、match_controller
控制器层典型实现
控制器类
依据功能的相关性，将一系列相关的功能，使用一个控制器类来处理，而该控制器的每个方法，就对因某个功能。
注意：控制器是按照功能划分的。（而不是像模型一样，按表来划分）
比赛相关功能控制器类：
前端控制器（请求分发器，入口文件）
以上的listAction()操作应该如何被调用呢？
实例化，并掉用方法即可！
在哪里实例化或调用呢？
增加一个可以实例化并调用控制器方法的文件。
逻辑流程：
动作action分发参数：a
如何做到一个前端控制器，可以调用一个控制器类不同方法动作呢？
在请求前端控制器index.php时，向其传递a参数，表示当前所需要执行的动作名，例如：
功能：比赛列表：
Index.php?a=list
功能：比赛删除：
Index.php?a=remove
Tip：链接地址的形成，应该在HTML代码中就确定好了，再存在一个默认动作即可！
Index.php判断a参数，执行相应的动作即可：
测试：
控制器controller分发参数：c
如果需要执行其他控制器的某个动作应该处理处理前端控制器？
在请求前端控制器index.php时，向其传递c参数，表示当前所需要执行的控制器类名，例如：
比赛的列表动作：
Index.php?c=Match&a=list
球队的信息动作
Index.php?c=Team&a=info&id=TID
c,a在HTML的链接地址中，自动形成好的
Index.php对c分发参数进行处理：
测试：
使用常量存储分发参数
思考：
在一次请求周期中，所请求的控制器名（当前控制器），和所请求的动作名（当前动作），是否会发生更改？
不会发生更改！
如何在语法的层面上，保证在一次请求周期内，当前控制器与当前动作不会发生改变？
存储在变量中，不能保证。
应该使用常量，进行存储当前控制器及其当前动作，保证
Index.php中实现：
基础控制器
增加为 所有的控制器提供基础代码控制器类：
Controller
其他控制器，继承自基础控制器：
初始化Content-Type的基础操作
Controller.class.php
调用：
在实例化控制器对象时调用，在构造方法中：
Controller.class.php
逻辑图例
注意：
浏览器的请求地址（URL），都是固定的形式：
Index.php?c=Controller&a=action&
称之为单入口模式
项目对外提供的任何功能，都是由某个控制器类的某个方法来实现的。