正确使用SailsJs策略，服务和模型

Question

我是NodeJs和SailsJs的新手，所以要好。

我一直在使用策略来完成POST请求，最终会创建一个新模型;

1. 检查是否存在所有请求参数的策略，如果缺少任何请求参数，则回复404或类似的
2. 调用服务以检查数据库中是否存在某个模型并且具有发生请求的正确状态的策略。此策略可能会在创建新模型后向请求中添加其他参数以供使用。
3. 与上述相同，适用于不同型号。
4. 现在我们知道这两个模型存在并且正确我们可以使用步骤3和4中使用的类似服务来修改它们。
5. 为新创建的模型调用OnCreate现在我们已经通过了所有策略，这将对新创建的模型进行一些最终修改。

为了检查请求并在请求中添加其他参数，这些策略似乎是个好主意。但它似乎有点麻烦。在最终修改其他模型之前，我需要检查所有内容。

似乎交易在这里会有所帮助，因为这样我就可以同时检查和更新所有交易。

我使用的是MongoDb。

Answer 1

我可能值得引用“Sails in action”，因为我今天早上正在阅读他们的政策最佳做法！

  

策略不应该是业务逻辑的核心部分   策略不是在应用程序中构建逻辑的好工具。以这种方式使用它们   使它们像原始Express / Connect中间件一样多功能 - 不幸的是   它也使它们同样危险和特定于开发人员。如果您使用政策来提供帮助   使用查询，或创建复杂的策略链来管理权限系统   在您的应用程序中，您可能会创建一个对其他任何人都很难的代码库   开发者要了解。

有了这样说，它接着建议：

  

政策不是在您的应用中构建逻辑的好工具。以这种方式使用它们   使它们像原始Express / Connect中间件一样多功能 - 不幸的是   它也使它们同样危险和特定于开发人员。如果您使用政策来提供帮助   使用查询，或创建复杂的策略链来管理权限系统   在您的应用程序中，您可能会创建一个对其他任何人都很难的代码库   开发者要了解。

基于以上引用，我认为您对政策的使用提出质疑是正确的。我认为你所描述的肯定是在第一个引用（接近结尾）描述的世界中。

对我来说，我会在可能的情况下致电服务。实质上，如果我最终在多个文件中使用代码3次以上，那么它需要存在于服务中。如果代码是自定义的每个动作，那么可以坐在控制器中。参数检查您是否属于控制器操作，除非您构建服务，否则您可以提供一些选项以进行验证。

我检查控制器中的参数，但您认为在模型级别执行验证甚至更有用？无论收到什么，模型都需要满足它具有有效属性。也许将逻辑推向你的模型更接近服务领域。

很高兴进一步讨论，风帆的好处是，从来没有一种最好的做法，但有些人以前已经感受到了痛苦并且可以提供一些指导。

  

不要看参数 -   真正可重复使用的策略应该只关注req.session和数据库 - 而不是   参数！依赖参数使您的策略特定于上下文并且仅可用   在非常特殊的情况下。在这种情况下，为什么不把代码放入   相关行动？

Answer 2

我也是SailsJS的新人。我只是使用策略验证authentication并在请求中插入logged用户（当我需要时）。对于其他验证，我使用beforeCreate(...) Lifecycle callback