Meteor基础模型

　　初入Meteor，定义好Collection之后，前后端均可以按mongo语法进行CRUD，这是因为每一个新项目均自动添加了insecure和autopublish两个包。按照官网的说法，这两个包可以帮助你快速地构建原型，但是在产品中，这是不安全的。因此，如果需要构建产品，一般都直接移除掉这两个包。那么没有这两个包之后，Meteor的基本模型是怎样的呢？本文在没有这两个包的情况下，尽力阐述Meteor的基本模型，在这之后解释这两个包的作用，就十分清楚了（它们为什么可以帮助你快速地构建原型）。

　　Collection是Meteor创建的模型，本质上就是Mongodb的collection。创建collection之后，后端代码就可以直接使用.进行操作了，其中，是mongodb的对应操作，如find, insert等。

　　这时，前端并不能直接访问这些模型（集合），于是需要引入publish/subscribe模式。首先，后端publish某些collection的子集，注意是collection的子集，比如publish 'tasks'时，return Tasks.find(...)。然后，前端subscribe需要的集合，比如subscribe 'tasks'，然后前端就可以访问这些集合了，比如Tasks.find(...)，注意，前端调用端时候用的是collection名称Tasks，而不是订阅时的tasks。

　　如上所述，前端可以操作的Tasks，实际上是后端publish出来的Tasks的子集。即使这时，前端仍然只能对订阅的集合进行查询（find），而不能修改（insert, remove, update）。

　　如果要允许前端直接修改集合，需要配合collection的allow方法。allow方法控制insert, remove, update的调用权限，当在给定环境下，对应的控制函数返回true的时候，前端即可以执行该操作。比如，allow里的insert函数，如果返回user.isRoot，那么之后当前用户是root的时候才能执行。

　　要允许前端修改集合，另一个更常用的方法是使用methods。methods是公共代码，前后端均可以调用，并且在methods中可以对集合进行完整的CRUD。

　　在这基础之上，现在解释autopublish和insecure包的作用。autopublish，顾名思义，就是将所有定义的集合自动publish，前端自动subscribe。而insecure包，就使得前端可以不通过allow或methods就直接调用collection的修改类代码。

　　综上，就Meteor的基础模型，首先，定义collection，然后，publish/subscribe需要的子集（可以查询），然后，定义methods（可以修改）。