我是NodeJs和SailsJs的新手,所以要好。
我一直在使用策略来完成POST请求,最终会创建一个新模型;
为了检查请求并在请求中添加其他参数,这些策略似乎是个好主意。但它似乎有点麻烦。在最终修改其他模型之前,我需要检查所有内容。
似乎交易在这里会有所帮助,因为这样我就可以同时检查和更新所有交易。
我使用的是MongoDb。
答案 0 :(得分:2)
我可能值得引用“Sails in action”,因为我今天早上正在阅读他们的政策最佳做法!
策略不应该是业务逻辑的核心部分 策略不是在应用程序中构建逻辑的好工具。以这种方式使用它们 使它们像原始Express / Connect中间件一样多功能 - 不幸的是 它也使它们同样危险和特定于开发人员。如果您使用政策来提供帮助 使用查询,或创建复杂的策略链来管理权限系统 在您的应用程序中,您可能会创建一个对其他任何人都很难的代码库 开发者要了解。
有了这样说,它接着建议:
政策不是在您的应用中构建逻辑的好工具。以这种方式使用它们 使它们像原始Express / Connect中间件一样多功能 - 不幸的是 它也使它们同样危险和特定于开发人员。如果您使用政策来提供帮助 使用查询,或创建复杂的策略链来管理权限系统 在您的应用程序中,您可能会创建一个对其他任何人都很难的代码库 开发者要了解。
基于以上引用,我认为您对政策的使用提出质疑是正确的。我认为你所描述的肯定是在第一个引用(接近结尾)描述的世界中。
对我来说,我会在可能的情况下致电服务。实质上,如果我最终在多个文件中使用代码3次以上,那么它需要存在于服务中。如果代码是自定义的每个动作,那么可以坐在控制器中。参数检查您是否属于控制器操作,除非您构建服务,否则您可以提供一些选项以进行验证。
我检查控制器中的参数,但您认为在模型级别执行验证甚至更有用?无论收到什么,模型都需要满足它具有有效属性。也许将逻辑推向你的模型更接近服务领域。
很高兴进一步讨论,风帆的好处是,从来没有一种最好的做法,但有些人以前已经感受到了痛苦并且可以提供一些指导。
不要看参数 - 真正可重复使用的策略应该只关注req.session和数据库 - 而不是 参数!依赖参数使您的策略特定于上下文并且仅可用 在非常特殊的情况下。在这种情况下,为什么不把代码放入 相关行动?
答案 1 :(得分:1)
我也是SailsJS的新人。我只是使用策略验证authentication并在请求中插入logged用户(当我需要时)。对于其他验证,我使用beforeCreate(...)
Lifecycle callback