Meteor 方法与拒绝/允许规则 [英] Meteor method vs. deny/allow rules
问题描述
在 Meteor 中，我什么时候应该更喜欢 方法 而不是 deny 规则?
In Meteor, when should I prefer a method over a deny rule?
在我看来，allow/deny 规则应该受到青睐，因为它们的目标更加明确，而且人们知道去哪里寻找它们.
It seems to me that allow/deny rules should be favoured, as their goal is more explicit, and one knows where to look for them.
然而，在 Discover Meteor 一书中，防止重复插入(重复"被定义为添加其 url 属性已经在同一集合的其他文档中定义的文档)据说具有通过方法定义(并作为练习留给读者，第 8.3 章).
However, in the Discover Meteor book, preventing duplicate insertions ("duplicate" being defined as adding a document whose url property is already defined in some other document of the same collection) is said to have to be defined through a method (and left as an exercise to the reader, chapter 8.3).
我认为我能够以一种我认为更清晰的方式实施这项检查:
I think I am able to implement this check in a way that I find much clearer:
Posts.deny({
update: function(userId, post, fieldNames, modifier) {
return Posts.findOne({ url: modifier.$set.url, _id: { $ne: post._id } });
}
});
(注意，如果你知道这个例子，是的，我自愿从问题中省略了仅修改了属性的一个子集"检查，以便更具体.)
我知道除了 $set 之外还有其他 更新操作符在 Mongo 中，但它们看起来是打字的，我不想留下安全漏洞.
I understand that there are other update operators than $set in Mongo, but they look typed and I don't feel like leaving a security hole open.
那么:我的deny 规则有什么缺陷吗?独立地，我应该赞成一种方法吗?我会从中得到什么?我会失去什么?
So: are there any flaws in my deny rule? Independently, should I favour a method? What would I gain from it? What would I lose?
推荐答案
通常我会尽量避免主观回答，但这是一个非常重要的辩论.首先，我建议阅读 Meteor 方法与客户端操作 来自 Discover Meteor 博客.请注意，在 Edthena，我们仅出于显而易见的原因使用方法.
Normally I try to avoid subjective answers, but this is a really important debate. First I'd recommend reading Meteor Methods vs Client-Side Operations from the Discover Meteor blog. Note that at Edthena we exclusively use methods for reasons which should become evident.
方法可以正确执行任意复杂性的模式和验证规则，而无需外部库.旁注 - check 是验证输入结构的绝佳工具.
Methods can correctly enforce schema and validation rules of arbitrary complexity without the need of an outside library. Side note - check is an excellent tool for validating the structure of your inputs.
每种方法都是您应用程序中的单一事实来源.如果您创建一个posts.insert"方法，您可以轻松确保它是您应用中插入帖子的唯一方式.
Each method is a single source of truth in your application. If you create a 'posts.insert' method, you can easily ensure it is the only way in your app to insert posts.
- 方法需要命令式风格，而且在操作所需的验证次数方面往往比较冗长.
allow/deny具有简单的声明式风格.
allow/denyhas a simple declarative style.
验证
update操作的架构和权限非常困难.如果您需要强制执行架构，则需要使用外部库，例如 collection2.光是这个原因就应该让你停下来.
Validating schema and permissions on an
updateoperation is infinitely hard. If you need to enforce a schema you'll need to use an outside library like collection2. This reason alone should give you pause.
修改可以遍布您的应用程序.因此，确定特定数据库操作发生的原因可能很棘手.
Modifications can be spread all over your application. Therefore, it may be tricky to identify why a particular database operation happened.
在我看来，allow/deny 更美观，但它的根本弱点在于强制执行权限(特别是在更新时).在以下情况下，我会推荐客户端操作:
In my opinion, allow/deny is more aesthetically pleasing, however it's fundamental weakness is in enforcing permissions (particularly on updates). I would recommend client-side operations in cases where:
您的代码库相对较小 - 因此很容易对出现特定修饰符的所有实例进行 grep.
Your codebase is relatively small - so it's easy to grep for all instances where a particular modifier occurs.
您的开发人员并不多 - 因此您无需所有人都同意只有一种方法可以插入 X 集合.
You don't have many developers - so you don't need to all agree that there is one and only one way to insert into X collection.
您有简单的权限规则 - 例如只有文档的所有者可以修改它的任何方面.
You have simple permission rules - e.g. only the owner of a document can modify any aspect of it.
在我看来，在构建 MVP 时使用客户端操作是一个合理的选择，但我会在所有其他情况下切换到方法.
In my opinion, using client-side operations is a reasonable choice when building an MVP, but I'd switch to methods for all other situations.
更新 2/22/15
Sashko Stubailo 创建了一个 提议来替换允许/拒绝使用插入/更新/删除方法.
Sashko Stubailo created a proposal to replace allow/deny with insert/update/remove methods.
更新 6/1/16
流星指南采取的立场是allow/deny 应该总是要避免.
The meteor guide takes the position that allow/deny should always be avoided.
这篇关于Meteor 方法与拒绝/允许规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
