我们正在构建具有非数据库组件的模型的应用程序。 我们很想知道其他人在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
部分原因是我们正在努力解决与铁路标准的接近程度以及创建一个对我们需要的产品有利的结构的程度。
如果我们将对象视为服务对象，我们可以
app/models/service-object
和
app/models/ # For plain active record
另一条下线路线是app内没有东西，例如
/service_objects
而不是
/app/models/service_objects
据推测，如果我们想要通过rails应用程序进行访问，我们最好使用app /以便利用约定优于配置。
答案 0 :(得分：14)
对于服务对象，您通常会将它们直接放在应用程序目录app/services/下。工作人员和序列化程序也遵循此模式app/workers/ app/serializers/。对于非AR的模型，您仍然可以将它们粘贴在模型目录中。这只是我对它的看法。
答案 1 :(得分：13)
根据我的经验，您将这些模型放在哪里，可以归结为它们在您的应用程序的特定环境中的功能。
我通常会为基于资源的模型保留app/models。如果该模型表示由应用程序实例化和操作的资源，那么它就在这里。不需要AR或db支持。
如果模型提供一致的功能但参数不同，我会在app中为他们提供顶级目录。例如app/mailers app/observers等。但是，如果您有一个需要观察者的资源，那么只有一个app/observers目录可能没有意义。
其他所有内容都在lib。有几个原因可以解释这个问题。
您可以选择何时需要lib中的文件。您可以更加有选择性地在应用启动时加载哪些文件。如果你把所有内容放在app/models中，那么你对所加载的内容没有任何粒度。
在lib中，随着应用程序的增长，命名空间模型。当然你可以在app/models中命名空间，但app/models中的几层嵌套总是令人讨厌。最好将命名空间保留在lib。
当您在功能正确的地方放置东西时，内务管理会变得更容易。这不是资源？这不是观察者？必须在lib。您将此想法放在前面的全部原因是为开发人员提供可发现性。
答案 2 :(得分：9)
如果它们是模型，则应将它们放入app/models，因为此目录适用于模型，而不仅仅是ActiveRecord子类。
答案 3 :(得分：2)
如果您的课程不是模特，例如他们可能代表一个表格，我会说继续将它们放在lib中。
如果它们与您的应用程序正交，即：它是用于调用另一个应用程序的某个接口，您可以将其包装为私有或公共gem，具体取决于它对社区其他人的适用性。
最后，它并不重要。选择一件事，并与团队的其他成员达成一致。移动东西应该非常简单，特别是如果你将你决定使用的东西添加到你的应用程序的加载路径（$LOAD_PATH += '...'）。