即，以下在 Meteor 中构建服务器端数据库 API 的方法的优缺点是什么？
基于方法
import Db from 'Db';
Meteor.method({"insert": (data) => {Db.insert(data)});
基于子类
import {Mongo} from "meteor/mongo";
class MyCollcetion extends Mongo.Collection {
insert: (data) => {super.insert(data);}
}
这个问题已经在下面解决了；有一个类似的问题需要进一步阅读：Meteor method vs. deny/allow rules
【问题讨论】：
标签： meteor
这主要是轻松与控制的问题。对于简单的事情，子类化可能更容易，方法更强大。
这也可能受到您的心态（或影响它）的影响：CRUD 与基于动作的突变。
insert/update/remove 与 CRUD 的心态相得益彰，同时您可以将方法与以操作为中心的 RPC 修改器相关联。
最终，这是个人喜好问题，所以我会尽量给出一个简短的事实描述，让读者根据自己的喜好来决定。
默认情况下，Meteor 在实例化集合时自动生成变异方法（insert、update、remove）。
这些方法在客户端调用MyCollection.insert(mutator, cb)时在后台调用（在客户端方法代码之外）。数据到达服务器后，首先通过允许/拒绝规则，然后执行。
子类化时，您覆盖这些方法并获得一个“挂钩”进入流程。
在定义 Meteor 方法时，您可以完全控制该过程。
您设置方法的参数和名称，您可以根据需要执行验证和授权。
您还可以创建一个方法存根供客户端使用，它会生成乐观的 UI，直到收到方法服务器执行的结果。
您可以使用 validatedMethod 之类的东西来为您的方法获得一些额外的验证逻辑和模块化。
您还可以通过在实例化集合时为defineMutationMethods 选项设置false 值来防止创建默认突变方法。您还可以通过提供适当的deny 规则来禁止来自客户端的直接突变。
虽然子类化允许您在客户端上使用 MyCollection.insert(...) 等，但您需要使用您定义的参数调用方法名称以改变数据。
【讨论】：
insecure 包后，客户端是否可以更改数据库？如果这是真的，那么方法是访问数据库的唯一方法。
insecure 包对于除了一次性原型之外的任何东西都不是一个好主意。
insecure 包，实际上我从一开始就删除了它。感谢您确认允许/拒绝规则是客户端对数据库突变的保护。