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