Rails:命名空间与引擎?

时间:2015-04-15 01:55:45

标签: ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4 devise

我刚刚在PHP世界中开始使用Rails项目。

这个项目还处于初期阶段,这意味着这是进行重大更改的好时机,目前包含两个不同的rails模块,一个用于管理员,另一个用于用户,两个都在单独的rails实例中。我想要做的是将两个项目合并到一个rails实例中,我相信从长远来看,它将提高应用程序的可管理性。

两个实例共享同一个数据库,每个实例都有一个用于身份验证的设计模型。我一直在记录合并两个项目的方法,我提出了两个选择:第一个是创建两个名称空间,一个用于用户,另一个用于管理员,并共享模型和框架逻辑。第二个是为管理员和用户创建引擎,这似乎更干净但更复杂。

我已阅读了很多文档,我正在尝试使用rails,但此时我需要更有经验的观点。

提前感谢您,感谢您对此的看法。

1 个答案:

答案 0 :(得分:4)

名称空间和引擎都有利有弊。使用哪一个将归结为您的特定用例。在大多数情况下,我建议使用命名空间,因为它往往更容易,并节省一些令人头疼的问题。特别是在共享数据模型时。但是,当您想要在多个应用程序中共享常见的隔离行为时,引擎很棒。

发动机

赞成

  • 隔离相关功能。如果您有一些仅由其中一个引擎使用的表,这是特别好的,因为它们可以使用前缀表名来管理自己的数据库迁移。
  • 可以在多个Rails应用程序中重用。 (在某些情况下)
  • 从单片Rails应用程序中提取代码时的良好起点。
  • 降低开发人员处理大型代码库的不同引擎的机会会破坏其他引擎中的功能。

缺点

  • 不是一个完全由引擎组成的应用程序的常见模式。因此,新工程师需要一些时间来适应所有设置的方式。
  • 分享常用功能会令人沮丧。例如。样式表
  • 您最有可能以意想不到的方式在两个引擎之间共享代码。这会带走Isolate related functionality福利的一些价值。
  • 使用Rails插件的文本编辑器往往有奇怪的行为。例如,vim插件快捷方式有时在插件目录
  • 内部时不起作用

命名空间

赞成

  • 简单易用,已经有很多Rails惯例可供使用。
  • 共享资产和其他常用功能往往非常简单。
  • 文本编辑器rails插件完全支持。

缺点

  • 不清楚哪些模型或库对不同的命名空间很重要。