简体繁体 English

Rails：命名空间与引擎？

[英]Rails : Namespacing vs Engines?

原文 2015-04-15 01:55:45 4 1 ruby-on-rails/ ruby/ ruby-on-rails-3/ ruby-on-rails-4/ devise

I am just getting started in a Rails project after a long time in the PHP world. 在PHP世界中待了很长时间之后，我才刚刚开始一个Rails项目。

This project is in a very early stage, meaning that is a good time to do major changes, and currently comprises two different rails modules, one for administrators and one for users, both in separate rails instances. 该项目处于早期阶段，这意味着是进行重大更改的好时机，并且目前包含两个不同的Rails模块，一个用于管理员，一个用于用户，都在单独的Rails实例中。 What I would like to do is to merge both projects into a single rails instance, which I believe it will improve the manageability of the application in the long run. 我想做的是将两个项目合并到一个单一的Rails实例中，我相信从长远来看，它将提高应用程序的可管理性。

Both instances share the same database and each of them has a devise model for authentication. 两个实例共享同一个数据库，并且每个实例都有用于身份验证的设计模型。 I have been documenting myself about ways of merging both projects and I came up with two alternatives: the first would be to create two namespaces, one for users and another one for admins, and share the model and framework logic. 我一直在记录自己有关合并两个项目的方式，我想出了两种选择：第一种是创建两个名称空间，一个用于用户，另一个用于管理员，并共享模型和框架逻辑。 the second one would be to create engines for admins and users, which seems to be cleaner but much more complex. 第二个方法是为管理员和用户创建引擎，这看起来更干净，但更为复杂。

I have read a lot documentation and I am experimenting with rails, but at this point I am in need of a more experienced opinion. 我已经阅读了很多文档，并且正在尝试使用Rails，但是在这一点上，我需要一个更有经验的意见。

Thank you in advance, and I appreciate your thoughts on this. 预先谢谢您，我感谢您对此的想法。

1 个解决方案

Both namespaces and engines have pros and cons. 命名空间和引擎都各有利弊。 Which one to use will come down to your particular use case. 使用哪一个取决于您的特定用例。 For the most part, I recommend using namespaces as it tends to be easier and saves some headaches. 在大多数情况下，我建议使用名称空间，因为它更容易使用并且可以减轻一些麻烦。 Especially when sharing a data model. 尤其是在共享数据模型时。 However, engines are great when you want to share common isolated behavior in multiple applications. 但是，当您想在多个应用程序中共享常见的隔离行为时，引擎非常有用。

Engines 引擎

Pros 优点

Isolate related functionality. 隔离相关功能。 This is especially good if you have some tables that are only used by one of the engines as they can manage their own database migrations with prefixed table names. 如果您有一些仅由其中一个引擎使用的表，则这特别好，因为它们可以使用带前缀的表名来管理自己的数据库迁移。
Can be reused in multiple Rails applications. 可以在多个Rails应用程序中重复使用。 (In some cases) （在某些情况下）
Good starting point when extracting code out of a monolithic Rails application. 从整体式Rails应用程序中提取代码的良好起点。
Reduces the chance that developers working on different engines of a large codebase will break functionality in one of the other engines. 减少使用大型代码库的不同引擎的开发人员破坏其他引擎之一的功能的机会。

Cons 缺点

Not a common pattern to have an application that is made up entirely of engines. 具有完全由引擎组成的应用程序不是一种常见的模式。 So it will take new engineers some time to get used to how everything is setup. 因此，新工程师将需要一些时间来习惯所有设置。
Can be frustrating to share common functionality. 共享通用功能可能会令人沮丧。 Eg stylesheets 例如样式表
You will most likely end up sharing code between the two engines in unexpected ways. 您很可能最终会以意外的方式在两个引擎之间共享代码。 Which takes away some value of the Isolate related functionality benefit. 这带走了与Isolate related functionality优势的某些价值。
Text editors with Rails plugins tend to have odd behavior. 带有Rails插件的文本编辑器往往具有奇怪的行为。 For example, the vim plugin shortcuts sometimes don't work when inside of a plugin directory 例如，在插件目录中时，vim插件快捷方式有时不起作用

Namespaces 命名空间

Pros 优点

Simple to use and already plenty of Rails conventions to follow. 简单易用，已经有很多Rails约定可以遵循。
Sharing assets and other common functionality tends to be very straightforward. 共享资产和其他常用功能往往非常简单。
Fully supported by text editor rails plugins. 文本编辑器Rails插件完全支持。

Cons 缺点