从本章开始就要揭开模型的神秘面纱了，本章主要学习模型的定义和基础使用，以及和数据库操作的区别，学习内容主要包含：

在说模型和数据库的区别之前，首先理解一点，5.0的数据库抽象访问层（我们后面用Db类表示）和模型是一个整体，共同完成了ThinkPHP5.0的ORM（对象关系映射）。或者也可以理解为模型是数据访问层的查询构造器延伸，完成更高级的数据库查询操作罢了。

通过前面几章的学习，看起来Db类已经非常的强大，但缺点仍然非常明显：

上面这些内容我只是打击下迷恋Db类的朋友，别无它意（因为本来就是故意设计的_）。

其实还有很多...当然，原因并不是否定Db类的实现，而是前面提到的，Db和模型本来就是一个整体，只是各自的职责和分工不同，如果没有Db类的基石，模型也只是建在沙滩上的城堡罢了。

Db和模型的存在只是ThinkPHP5.0架构设计中的职责和定位不同，Db负责的只是数据（表）访问，模型负责的是业务数据和业务逻辑。

当然，模型层可以分的更细，把数据模型和逻辑模型，甚至服务模型分开，这个暂时就不在目前的讨论范畴了，只不过把模型层的职责和分工更细化。

如果你用框架只是用来管理一些数据的CURD而没有业务需要（其实本质上来说任何的系统都是CURD，业务逻辑都是抽象和封装出来的，这是设计层面的问题了），那么也许看起来Db类已经够用了（你不觉得其实数据库本身已经可以完成了么），但是作为一个业务系统或者平台（无论是WEB还是API），通常每个数据表就对应了一个业务模型对象，甚至存在和其它业务模型的混合和关联逻辑。举个用户表的例子，用户登录这样一个业务逻辑其实包含了很多的关联操作，你得检查用户账号是否正常，用户名和密码是否正确，然后记录用户的最后登录时间和IP（如果IP所在区域不符有些系统还需要给用户发邮件提醒），还要给用户增加积分，甚至可能还需要检查用户的权限，那么Db类就显得吃力了，这其实也是数组存储结构和对象存储设计的差异，业务越复杂，这种差异越明显，PHP的数组再强大也替代不了对象。

Db和模型最明显的一个区别就是Db查询返回的数据类型为数组（对于一个没有业务逻辑的数据而言，数组已经足够），而模型的查询返回类型的是模型对象实例。

也许前面几个问题你根本不会在意（确实优雅只是看起来舒服一些罢了，关联用JOIN还容易掌控之类的话我也经常听到，呵呵~），但最后一个问题无法封装业务逻辑是致命的，处理不当极易出现违反MVC架构设计的混乱情况。

再说简单一点，由于Db类的数据操作并没有一个唯一对应的对象实例，也就无法封装业务方法，就变成你的业务方法要么写到控制器方法里面，要么定义到另外一个所谓的“业务逻辑”层里面，前者显然是违反MVC架构设计思想的，而后者其实就是一个模型类的概念存在了，那么是否需要拥抱模型就显而易见，不用我多说了吧_

话说回来了，有些人虽然用了模型，但仍然在模型里面大量封装直接操作Db类的代码和方法，这也是一种伪模型设计，并不可取。

比较Db和模型，不要单纯从功能上做比较，这是次要的，也没意义，毕竟职责定位不同。也不要在意性能上的差异，这个对于业务逻辑来说，一次查询就抵消了。

总而言之，想要掌握模型，必须明白和理解下面几个原则：

模型设计基于数据访问层之上，并作了更高层次的封装，实现了Db类本身不支持的功能，或者简化了原本使用Db类的复杂操作。从查询操作的角度来看，可以理解为Db类是数据表的查询构造器，而模型是业务模型的查询构造器，其实都属于查询构造器的范畴。

很多人不习惯用模型的原因无非就几个方面：

我们会慢慢打消上述的这些困惑或顾虑，学完本书，你就会发现模型其实很简单，而且相对于Db查询来说牺牲的细微性能完全值得。

在控制器中永远调用的是模型类，然后在模型类中封装业务逻辑方法和数据处理，完成业务操作。对控制器来说，模型就是一个业务逻辑接口，并且善于运用依赖注入机制来绑定模型对业务操作会带来极大的便利。

定义一个模型很简单，下面是一个最简单的模型类：