Rails:命名空间与引擎?

And*_*res 3 ruby ruby-on-rails devise ruby-on-rails-3 ruby-on-rails-4

在 PHP 世界中待了很长时间后,我才刚刚开始一个 Rails 项目。

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

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

我已经阅读了很多文档并且我正在尝试使用 rails,但是在这一点上我需要一个更有经验的意见。

在此先感谢您,我感谢您对此的想法。

小智 7

命名空间和引擎各有利弊。使用哪一个取决于您的特定用例。在大多数情况下,我建议使用命名空间,因为它往往更容易并且省去了一些麻烦。特别是在共享数据模型时。但是,当您想在多个应用程序中共享共同的隔离行为时,引擎非常有用。

引擎

优点

  • 隔离相关功能。如果您有一些仅由其中一个引擎使用的表,这尤其好,因为它们可以使用带前缀的表名来管理自己的数据库迁移。
  • 可以在多个 Rails 应用程序中重用。(在某些情况下)
  • 从整体式 Rails 应用程序中提取代码的良好起点。
  • 减少开发人员在大型代码库的不同引擎上工作破坏其他引擎之一功能的可能性。

缺点

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

命名空间

优点

  • 使用简单,并且已经有大量的 Rails 约定可以遵循。
  • 共享资产和其他常见功能往往非常简单。
  • 完全由文本编辑器 rails 插件支持。

缺点

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