我们正在构建的应用程序的模型不是数据库组件。我们很想了解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/,以便利用约定而不是配置。
发布于 2013-05-17 07:44:56
根据我的经验,放置这些模型的位置的划分取决于它们在应用程序的特定上下文中的功能表示。
我通常为基于资源的模型保留app/models。如果该模型表示由您的应用程序实例化和操作的资源,则它位于此处。不需要AR或数据库支持。
如果模型提供一致的功能,但参数不同,我会在app中给它们一个顶级目录。例如app/mailers app/observers等。但是,如果您有一个需要观察者资源,那么只包含一个文件的app/observers目录可能没有意义。
其他所有内容都放在lib中。有几个原因说明为什么这样做更可取。
lib中的文件。当你的应用程序启动时,你可以更有选择性地选择加载哪些文件。如果你把所有的东西都放在app/models中,你就没有粒度来决定什么是loaded.app/models中使用名称空间,但是app/models中的几层嵌套总是以令人讨厌的方式结束。当你把东西放在功能正确的地方时,最好让lib.lib中。你把心思放在这上面的全部原因是为了向以后的开发人员提供可发现性。发布于 2013-05-10 00:03:23
对于服务对象,通常将它们直接放在应用程序目录app/services/下。工作进程和序列化程序在app/serializers/中也遵循这种模式。对于不是AR的模型,您仍然可以将它们放在models目录中。这只是我对它的看法。
发布于 2013-05-16 22:41:21
如果它们是模型,那么您应该将它们放到app/models中,因为这个目录是用于模型的,而不仅仅是ActiveRecord子类。
https://stackoverflow.com/questions/16466024
复制相似问题