模型是 MVC 模式中的一部分， 是代表业务数据、规则和逻辑的对象。
可通过继承 [[yii\base\Model]] 或它的子类定义模型类，基类[[yii\base\Model]]支持许多实用的特性：
- 属性: 代表可像普通类属性或数组一样被访问的业务数据;
- 属性标签: 指定属性显示出来的标签;
- 块赋值: 支持一步给许多属性赋值;
- 验证规则: 确保输入数据符合所申明的验证规则;
- 数据导出: 允许模型数据导出为自定义格式的数组。
属性：
所有 non-static public非静态公有 成员变量都是属性，如果是对应数据库的模型，我发现表的字段都是他的属性，而且是默认已经声明的，可以不用在手动声明。
属性标签：
这个主要是在视图中使用，而且为了统一修改，很方便的。通过方法 attributeLabels 返回一个数组或对象，我发现2.0以后的多少用对象代替了以前的数组方式。
1 public function attributeLabels(){
2 return [
3 ‘name‘ => ‘Your name‘,
4 ‘email‘ => ‘Your email address‘,
5 ‘subject‘ => ‘Subject‘,
6 ‘body‘ => ‘Content‘,
7 ];
8 }
场景：
一个模块可以在多个场景下使用，比如用户模型可以在注册和登录场景下使用，而且他们的验证规则甚至属性标签会有所不同，这就有了场景存在的必要性。可以通过 scenarios函数来实现。
1 public function scenarios(){
2 $scenarios = parent::scenarios();
3 $scenarios[‘login‘] = [‘username‘, ‘password‘];
4 $scenarios[‘register‘] = [‘username‘, ‘email‘, ‘password‘];
5 return $scenarios;
6 }
其中 $scenarios = parent::scenarios(); 可以保持默认场景的情况下，设置新场景的情况。
验证规则：
主要是针对表单的输入内容作出验证，比如用户名不能为空，email不能为空且必须是个邮箱的格式等等。可调用 [[yii\base\Model::validate()]] 来验证接收到的数据， 该方法使用[[yii\base\Model::rules()]]申明的验证规则来验证每个相关属性， 如果没有找到错误，会返回 true，否则它会将错误保存在 [[yii\base\Model::errors]] 属性中并返回false。
1 $model = new \app\models\ContactForm;
2
3 // 用户输入数据赋值到模型属性
4 $model->attributes = \Yii::$app->request->post(‘ContactForm‘);
5
6 if ($model->validate()) {
7 // 所有输入数据都有效 all inputs are valid
8 } else {
9 // 验证失败：$errors 是一个包含错误信息的数组
10 $errors = $model->errors;
11 }
1 public function rules(){
3 return [
4 // 在"register" 场景下 username, email 和 password 必须有值
5 [[‘username‘, ‘email‘, ‘password‘], ‘required‘, ‘on‘ => ‘register‘],
6
7 // 在 "login" 场景下 username 和 password 必须有值
8 [[‘username‘, ‘password‘], ‘required‘, ‘on‘ => ‘login‘],
9 ];
10 }
在rules方法中还可以标明这个规则是在哪个场景下使用的，如不是所有场景的话，就省去 ‘on‘=>‘‘，一行可以设置多个字段的规则也可以多行设置一个字段的规则，根据实际情况来做。
块赋值：
这个其实是个很好的东西，可以快速赋值表单传来的值，比如下面的赋值方式就把整个 ContactForm 表单的值赋值过来了。
$model = new \app\models\ContactForm; $model->attributes = \Yii::$app->request->post(‘ContactForm‘);
安全属性：
块赋值只应用在模型当前[[yii\base\Model::scenario|scenario]]场景[[yii\base\Model::scenarios()]]方法 列出的称之为 安全属性 的属性上，例如，如果User模型申明以下场景， 当当前场景为login时候，只有username and password 可被块赋值，其他属性不会被赋值。
public function scenarios(){
return [
‘login‘ => [‘username‘, ‘password‘],
‘register‘ => [‘username‘, ‘email‘, ‘password‘],
];
}
由于默认[[yii\base\Model::scenarios()]]的实现会返回[[yii\base\Model::rules()]]所有属性和数据， 如果不覆盖这个方法，表示所有只要出现在活动验证规则中的属性都是安全的。
为此，提供一个特别的别名为 safe 的验证器来申明哪些属性是安全的不需要被验证， 如下示例的规则申明 title 和 description 都为安全属性。
public function rules(){
return [
[[‘title‘, ‘description‘], ‘safe‘],
];
}
非安全属性：
相对于安全属性就有非安全属性，在某些情况下，你可能想验证一个属性但不想让他是安全的，可在scenarios()方法中属性名加一个惊叹号 !。例如像如下的secret属性。他的赋值就要单独的显式赋值。
public function scenarios(){
return [
‘login‘ => [‘username‘, ‘password‘, ‘!secret‘],
];
}
$model->secret = $secret;
数据导出：
其实简单说就是获取数据表的一个结果集，最简单的就是使用 attributes方法。
$post = \app\models\Post::findOne(100); $array = $post->attributes;
更灵活和强大的将模型转换为数组的方式是使用 [[yii\base\Model::toArray()]] 方法， 它的行为默认和 [[yii\base\Model::attributes]] 相同， 但是它允许你选择哪些称之为字段的数据项放入到结果数组中并同时被格式化。 实际上，它是导出模型到 RESTful 网页服务开发的默认方法。
字段：
字段是模型通过调用[[yii\base\Model::toArray()]]生成的数组的单元名。默认情况下字段和属性是对应的。但是你可以通过覆盖 [[yii\base\Model::fields()|fields()]] 和/或 [[yii\base\Model::extraFields()|extraFields()]] 方法来改变这种行为， 两个方法都返回一个字段定义列表，fields() 方法定义的字段是默认字段，表示toArray()方法默认会返回这些字段。 extraFields()方法定义额外可用字段，通过toArray()方法指定$expand参数来返回这些额外可用字段。 例如如下代码会返回fields()方法定义的所有字段和extraFields()方法定义的prettyName and fullAddress字段。
$array = $model->toArray([], [‘prettyName‘, ‘fullAddress‘]);
可通过覆盖 fields() 来增加、删除、重命名和重定义字段，fields() 方法返回值应为数组， 数组的键为字段名，数组的值为对应的可为属性名或匿名函数返回的字段定义对应的值。 特使情况下，如果字段名和属性定义名相同，可以省略数组键，例如：
// 明确列出每个字段，特别用于你想确保数据表或模型属性改变不会导致你的字段改变(保证后端的API兼容).
public function fields(){
return [
// 字段名和属性名相同
‘id‘,
// 字段名为 "email"，对应属性名为 "email_address"
‘email‘ => ‘email_address‘,
// 字段名为 "name", 值通过PHP代码返回
‘name‘ => function () {
return $this->first_name . ‘ ‘ . $this->last_name;
},
];
}
// 过滤掉一些字段，特别用于你想继承父类实现并不想用一些敏感字段
public function fields(){
$fields = parent::fields();
// 去掉一些包含敏感信息的字段
unset($fields[‘auth_key‘], $fields[‘password_hash‘], $fields[‘password_reset_token‘]);
return $fields;
}
除了上面说的模型自身的东西外，在使用的时候也应注意一些事情：
- 不应直接访问请求，session和其他环境数据，这些数据应该由控制器传入到模型;
- 应避免嵌入HTML或其他展示代码，这些代码最好在 视图中处理;
- 单个模型中避免太多的 场景.
在开发大型复杂系统时应经常考虑最后一条建议， 在这些系统中，模型会很大并在很多地方使用，因此会包含需要规则集和业务逻辑， 最后维护这些模型代码成为一个噩梦，因为一个简单修改会影响好多地方， 为确保模型好维护，最好使用以下策略：
- 定义可被多个 应用主体 或 模块 共享的模型基类集合。 这些模型类应包含通用的最小规则集合和逻辑。
- 在每个使用模型的 应用主体 或 模块中， 通过继承对应的模型基类来定义具体的模型类，具体模型类包含应用主体或模块指定的规则和逻辑。
例如，在高级应用模板，你可以定义一个模型基类common\models\Post， 然后在前台应用中，定义并使用一个继承common\models\Post的具体模型类frontend\models\Post， 在后台应用中可以类似地定义backend\models\Post。 通过这种策略，你清楚frontend\models\Post只对应前台应用，如果你修改它，就无需担忧修改会影响后台应用。