tp6中的模型

tp中获取数据库的数据有两种方式 ：

一是db连接数据库的方式直接获取数据，这个数据就是数据库中直接拿到的数据。

二是使用model模型，这种方式返回的是一个数据集(select方法 \think\model\Collection)或者数据模型对象(find方法 \think\model\Model) ,这个数据集其实包含多个数据模型对象的数组, 但不管是数据集还是模型对象 ， 都具有模型的方法 ， 而数据库的数据就放在模型对象的data属性当中。

很多人包括我一开始会觉得使用模型会使得查询效率低很多，为啥还有使用它，但是经过一段时间的使用以及对模型的更加深入的使用和理解，才发现模型真正的意义所在。我们使用数据库查询，只是为了单纯拿到数据库的数据，而模型查询获取的不单单是数据库的数据，更多的是它内部的封装的属性和方法。

设想一下，在我们日常的一个业务逻辑中，需要拿到一组数据，这个数据拿到就是数据库里面保存的那些数据吗？

答案显然不是 ， 并不是所有的字段都直接符合我们的业务需求，我们势必要在拿到这些数据后，做进一步的数据，最终将所需要的数据格式传递给客户端。但是有个问题 ， 我们的业务逻辑更多的应该是根据拿到的数据，去分析和处理使用者和数据间的一种关系，或者几个动作之间的关系，最终得出我们的结果，业务逻辑更多的是拿数据去分析，而不是花费大量的代码空间去重新组合处理这些数据 ， 这些操作并不应该太多的在业务中出现 ， 因为它会使得结构不够明确 ， 而且将数据处理和业务逻辑混合在一起 ， 很不利于后期的修改和维护。

这时候，其实就体现出了模型的重要性了 ， 模型其实是一个实例化之后的模型对象 ， 它其中不但有我们所需要从数据库中查询出的数据 ， 而且包含很多内置的属性和方法 ，甚至我们还可以为所有的模型添加公共的属性和方法，以及单独为个别的模型扩展属性和方法，像tp6中内置的获取器 ， 修改器 ， 类型转换 ， 字段只读 ，字段隐藏，搜索器 ， 自动时间戳 ， 软删除 ，模型关联。。。这些属性和方法 ， 可以让我们无需关注其内部实现细节，只需要简单继承或重写 ， 就可以实现我们需要花费大量代码空间所实现的功能，而且它的稳定性更高 ， 后期也更加容易维护和升级 ， 这其实也是AOP思想的一种体现。

因此 ， 模型不是简单的数据库查询 ， 它本身就是一个逻辑层，他所带来不仅仅是数据 ， 还有许多数据的处理和封装 ， 以及提供简单的业务处理能力。