流星方法与拒绝/允许规则 [英] 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.
但是，在发现流星"一书中，据说必须通过以下方法来防止重复插入(重复"被定义为添加其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 } });
}
});
(NB，如果您知道示例，是的，我自愿从问题中省去了仅修改属性的子集"检查，以使其更加具体.)
我了解到，除了$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?
推荐答案
通常，我会尽量避免主观回答，但这是一个非常重要的辩论.首先，我建议阅读流星方法与客户端操作从发现流星"博客中获取.请注意，在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.
-
方法可以正确地执行任意复杂度的架构和验证规则，而无需外部库.旁注-检查是验证输入结构的绝佳工具.
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
The meteor guide takes the position that allow/deny should always be avoided.
这篇关于流星方法与拒绝/允许规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
