【问题标题】:Correctly using SailsJs policies, services and models正确使用 SailsJs 策略、服务和模型
【发布时间】:2016-05-11 08:46:23
【问题描述】:

我是 NodeJs 和 SailsJs 的新手,所以请客气。

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

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

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

似乎事务在这里会有所帮助,因为这可以让我同时检查和更新所有内容。

我正在使用 MongoDb。

【问题讨论】:

    标签: sails.js sails-mongo


    【解决方案1】:

    可能值得我从“Sails in action”中引用,因为我今天早上实际上正在阅读他们的最佳政策实践!

    政策不应成为业务逻辑的核心部分 策略不是构建应用程序逻辑的好工具。以这种方式使用它们 使它们与原始 Express/Connect 中间件一样通用——不幸的是 这也使它们变得危险且特定于开发人员。如果您使用政策来帮助 使用查询,或创建复杂的策略链来管理权限系统 您的应用程序,您可能会创建一个对任何其他人都非常困难的代码库 开发者理解。

    话虽如此,它继续建议:

    策略不是构建应用程序逻辑的好工具。以这种方式使用它们 使它们与原始 Express/Connect 中间件一样通用——不幸的是 这也使它们变得危险且特定于开发人员。如果您使用政策来帮助 使用查询,或创建复杂的策略链来管理权限系统 您的应用程序,您可能会创建一个对任何其他人都非常困难的代码库 开发者理解。

    基于以上引用,我认为您对政策的使用提出质疑是正确的。我认为您所描述的内容肯定正在逐渐进入第一个引用所描述的世界(接近尾声)。

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

    我检查了控制器中的参数,但您认为在什么时候在模型级别执行验证可能更有用?不管接收到什么,模型都需要满足它具有有效的属性。也许将逻辑移到更靠近您的模型并移出服务领域。

    很高兴进一步讨论,风帆的好处是永远没有最佳实践,但有些人之前已经感受到了痛苦并且可以提供一些指导。

    不要看参数 - 真正可重用的策略应该只关注 req.session 和数据库——而不是 参数!依靠参数使您的策略特定于上下文且仅可用 在非常特殊的情况下。在那种情况下,为什么不把代码放在 相关操作?

    【讨论】:

    • 感谢@munkee。这是一个很大的帮助!看起来我应该覆盖生成的控制器中的默认操作。因此,与其在策略中执行检查、验证等,不如在我的控制器中的create 函数中进行。我确实这样做了,但似乎没有一种简单的方法可以在我的自定义代码运行后继续执行默认的create 操作?除了将默认代码复制到我自己的create 操作中?
    • 根据经验,我会让 create 操作单独执行它的标准操作。我会创建一个新动作来涵盖任何特定的内容,如果需要的话,我什至可以称之为“customcreate”。我 100% 建议购买 Sails.js in action book,因为我可以在这些帖子中与您的很多观点相关,直到我浏览某些章节,我才看到一些正在谈论的陷阱以及什么是“最佳实践”。简而言之,建议始终保持默认蓝图操作不受影响(99% 的情况)
    • 再次感谢。我不确定这对我有什么用,因为有几个模型需要检查和更改以获取例如波峰。 create 似乎是放置这些的正确位置,我还能把它们放在哪里?在生命周期事件中?
    • 在这样的情况下,我认为只做你认为最好的事情是值得的。我不知道您的完整应用程序架构来说明现在最好的方法是什么,但我认为我们讨论的要点表明,在某些领域您通常不会放置逻辑。如果您觉得生命周期事件可行,请尝试一下。作为最坏的情况,您在某个时候正在重构,但通过尝试您会学到更多。 Sails 非常适合这些场景,我很高兴它允许多个选项,而不是其他会迫使你走他们的路或“不行”的框架。
    【解决方案2】:

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-05-17
      • 2020-11-17
      • 1970-01-01
      • 1970-01-01
      • 2011-03-27
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多