22

我们正在构建具有不是数据库组件的模型的应用程序。我们很想知道 Rails 社区中的其他人正在做什么来解决这个问题。

我们正在努力将它们放在哪里。

我们应该有：

app/models/domain

或者

app/domain/models

也许

app/models   # Business Models
app/models/ar # Active Record Models

也许

app/models/domain/   # Business Models
app/models/domain/ar # Active Record Models

部分原因是我们正在努力与 Rails 标准的接近程度以及创建一个对我们需要的结构有益的结构。

如果我们将对象视为服务对象，我们可以有

app/models/service-object

和

app/models/ # For plain active record

另一个失败的途径是应用程序内没有东西，例如

/service_objects

代替

/app/models/service_objects

据推测，如果我们想通过 Rails 应用程序访问，我们最好使用 app/ 以利用约定优于配置。

4

4 回答 4

18

根据我的经验，将这些模型放在哪里的划分归结为它们在应用程序的特定上下文中的功能代表。

我通常保留app/models基于资源的模型。如果该模型表示由您的应用程序实例化和操作的资源，则它位于此处。不需要支持 AR 或 db。

如果模型提供一致的功能但参数有所不同，我会在应用程序中为它们提供顶级目录。诸如此类app/mailers app/observers。但是，如果您有一个需要观察者的资源，那么app/observers只有一个文件的目录可能没有意义。

其他的都进去了lib。有几个原因表明这是可取的。

  1. 您可以选择何时需要lib. 您可以对应用启动时加载哪些文件更有选择性。如果你把所有东西都放进去，app/models那么你就无法确定加载的内容。

  2. 随着应用程序的增长，为模型命名空间在 lib 中更容易。当然你可以命名空间，app/models但多层嵌套app/models总是令人讨厌。最好将命名空间保留在lib.

  3. 当你把东西放在功能正确的地方时，家务管理会容易得多。不是资源吗？不是旁观者吗？必须在lib. 您预先考虑这一点的全部原因是为开发人员提供可发现性。

于 2013-05-16T23:44:55.617 回答
14

对于服务对象，您通常会将它们直接放在 app 目录下app/services/。工作者和序列化程序也遵循这种模式app/workers/ app/serializers/。至于不是 AR 的模型，您仍然可以将它们粘贴在模型目录中。这只是我的看法。

于 2013-05-09T16:03:22.603 回答
10

如果它们是模型，则应将它们放入，app/models因为此目录用于模型，而不仅仅是 ActiveRecord 子类。

于 2013-05-16T14:41:20.650 回答
2

如果你有不是模型的类，例如它们可能代表一个表单，我会说继续把它们放在lib.

如果它们与您的应用程序正交，即：它是用于调用另一个应用程序的某个接口，您可以根据其对社区其他成员的适用性将其包装为私有或公共 gem。

最后，这并不重要。选择一件事，并与团队的其他成员达成一致。移动东西应该很容易，特别是如果您将决定使用的任何内容添加到应用程序的加载路径中（$LOAD_PATH += '...'）。

于 2013-05-15T22:44:34.997 回答