对于在何处放置在Rails应用类,不适合任何地方的指导方针(guidelines for where

2019-07-21 03:02发布

如果有什么地方就摆在Rails应用非标准Ruby文件,那些不属于任何缺省目录(任何的最佳做法我想知道controllers / models等)。

我说的是由控制器/模型等使用的类,但都没有任何的Rails基类的子类。 类,包括从模型中提取的功能,使他们较少的脂肪。 那种其中一些看起来像模特,但不是AR模型,其中一些看起来更像是“服务”,有些是介于两者之间或别的东西。

一些随机的例子:

  • “战略”类,处理与密码验证,通过Facebook等。
  • “XParams”封装params中,“XCreator”对象处理则params的处理来进行一些复杂的行动,导致最终创造一些AR模型对象
  • 类,使得请求外部API或封装这些请求和响应
  • 可以代替真正的AR模型假模型(如guest用户)
  • Resque工作
  • 存储和读取信息的Redis班
  • 即执行类似的处理数据的一些具体行动,生成报表等,并从Resque工作或耙任务被称为类

我有相当多的这些,现在,他们中的一些被添加到lib的一堆随机类和模块,这些模块结束了,有的潜入app/models 。 我想以某种方式组织这一点,但我不知道从哪里开始。

应该只AR模型进入app/models ? 还是确定还放在那里的任何域或辅助模型? 你如何决定,如果事情是一个模式?

如果不适合所有app进入lib ? 或者,也许我应该添加一些新的自定义子目录app ? 什么子目录,以及如何划分的自定义类?

你如何在你的项目处理呢? 我知道每一个项目是一个有点不同,但必须有一些相似之处。

Answer 1:

很好的问题 - 我没有给你一个具体的答案

但我建议您查看这篇文章- http://blog.codeclimate.com/blog/2012/02/07/what-c​​ode-goes-in-the-lib-directory/ -一定要通过所有评论阅读

在当前的项目,我有一吨的非ActiveRecord的下应用程序/模型对象,它的工作原理,但并不理想,我把“可重复使用的”非应用程序特定代码lib下

我已经在侧面项目尝试了其他替代品(比如说,我们有一大堆的命令对象的)Rails是一个痛苦,当谈到下的应用程序的命名空间,它加载一切成默认的相同的命名空间

app/
  commands/
    products/create_command.rb         # Products::CreateCommand
    products/update_price_command.rb   # Products::UpdatePriceCommand

交替,一切除了src下轨或APP_NAME目录

app/
  src/
    commands/
      create_product.rb         # Commands::CreateProduct
      update_product_price.rb   # Commands::UpdateProductPrice

我还没有碰到过一个很好的解决方案来为这一点,最好的第2个的为佳,但会是不错的,无权根据应用程序的其他目录,这样你打开的应用程序,看看控制器,命令,型号等...



Answer 2:

你触及了许多不同的使用情况,我认为这部分是最接近于“正确”的答案:

我有相当多的这些,现在,他们中的一些被添加到lib中的一堆随机类和模块,这些模块结束了,有的潜入应用/模型。 我想以某种方式组织这一点,但我不知道从哪里开始。

这是相当多的权利在我的书。 有一件事你没有提的是提取各种片段到各自的宝石。 这跟外部服务类是用于提取的最佳候选,因为是战略类,如果他们足够一般。 这些可以是私有的,因为运行自己的服务器的宝石不硬,然后你可以跨明显ROR应用程序重复使用。

最后,最具体,resque工作我塞进LIB /工作。

我的经验法则是,如果它是某种类型的模型,它进入app/models 。 如果不是,它可能属于在lib或一些适当命名的子目录物,如lib/jobslib/extensionslib/external ,等等。



Answer 3:

我把在任何模型类(如STI子类) apps/models 。 我把我的其他类lib ,因为它似乎是把他们的最佳场所。 这是容易的,我知道去哪里找。 这对我来说也更容易组我的测试,因为我的模型类都在同一个地方。

公约明智的,我讨厌把助手类的app/models 。 如果他们是主持人班它们属于在app/helpers 。 如果他们不那么lib似乎是对他们最好的去处。



Answer 4:

如果你有兴趣,我也写了一篇关于这个后续的文章稍晚总结我发现了什么: http://blog.lunarlogic.io/2013/declutter-lib-directory/



Answer 5:

通常我的班找到自己的方式进入lib子目录中,因为具有相同名称的子目录模块负责,包括他们。 (Rails是一个关于文件名和类名很敏感,当涉及到磁带自动加载。)

另一种选择是每个模块封装到自己的宝石,然后通过你的Gemfile指宝石。 这允许跨项目的代码共享。



文章来源: guidelines for where to put classes in Rails apps that don't fit anywhere