贯穿基本的Party Meteor示例（http://meteor.com/examples/parties），
我想知道为什么你需要使用Collection.allow指定哪些插入，更新等...而不是仅使用Meteor.methods然后从客户端发出Meteor.call。
似乎“方法”方式总是更好，因为它更灵活（即自定义函数）
答案 0 :(得分：8)
allow和deny界面足够灵活，可以满足您的大多数访问控制。如果您可以使用内置函数，那么最终会得到更清晰，更易理解，更易读的代码。它也更像Meteoric，因为它保留了Meteor的“数据库无处不在”抽象，能够直接在客户端上执行数据库操作。
可以拒绝集合上的所有操作，然后只通过方法公开对集合的访问。但是你最终有可能最终重新实现CRUD接口，并且你可能最终会重新实现允许和拒绝功能。
如果我发现难以通过allow and deny接口表达我需要的访问控制，我尝试只使用Meteor.methods。例如，有时您需要一次更新两个相关集合，并且验证需要在确定操作是否应继续之前检查对两个集合的建议更改。使用Meteor.method更清洁。
答案 1 :(得分：0)
您误解了Collection.allow目的：它用于限制客户端代码可以对您的集合执行的操作。这些限制不适用于服务器端。而且您确实应该在Meteor.methods中对集合执行写操作，然后从客户端代码中调用它们。
Collection.allow是为了防止最终用户和潜在的黑客能够用你的数据做他们喜欢的东西。永远不要忘记您的客户端代码可以使用。
在您提到的示例中，假设您的Party结构中有另一个字段。您可能不希望我能够更新此字段。如果没有对缔约方的字段名称进行“更新”回调测试，我将能够在该字段中进行更改。
明白这一点？