我目前正在将应用程序升级到rails 4.我计划为少数人安装此应用程序，但他们有不同的需求。我决定使用这个升级版本时间将我的一些模型放在引擎中。目标是花更少的时间来调整应用程序以满足情况的需要。核心应用程序将管理基本资源，引擎将添加功能（该应用程序正在管理小型组织的成员资格）。 我阅读了很多文档，包括“指南”。我测试了一些引擎来查看应用程序的行为。以下是我无法通过搜索回答的问题：
1 - 命名约定：
你如何命名引擎？我的第一次尝试是通过它们的功能命名它，但是当我生成我的第一个模型时，我看到我不能使用函数名称作为我的模型。
我想的是：Coreappname_functionality
例如我想为我的成员添加活动，引擎将命名为：member_activities
2 - 完全vs可安装
我读了很多关于这个主题的内容，很多人似乎都使用可安装引擎。我尝试了他们两个，我认为完整的选项实现起来非常快（没有路由，没有我必须注意的命名空间隔离）。但我也理解班级碰撞的风险。如果我是唯一一个为这个应用程序编写代码的人，使用完整引擎是一个坏习惯（这只是一个懒惰的问题）。即使我不打算在其他应用程序中使用它们，是否还有其他可安装引擎的优点？
3 - “如果引擎存在？”
在核心应用程序中，我将放置所有引擎所需的代码。例如，在侧栏内我想显示最后一个活动的列表，但仅在使用活动引擎时。目标是将所有必要的代码放在核心应用程序中，但是根据引擎的现状使用此代码。
在我的测试期间，我使用了：
if defined? Activity
@activities = Activity.all
end
并将其视图呈现如下：
<% if defined? Activity %>
<h3><%= @activities.first.title %></h3>
<% end %>
它运作良好，但我不确定这是一个好习惯。还有其他选择吗？
在我进入发动机世界之前，你有任何建议吗？ 我更喜欢在尝试之前发布我的问题，而不是在尝试后发布我的错误！
答案 0 :(得分：2)
对于那些阅读...
的人我认为对于孤立引擎的含义存在误解。实际上它有点令人困惑。有些人可能认为在孤立和非孤立之间做出选择有点像偏好。但这并不完全正确。
孤立的引擎就是这样。孤立的引擎。它不适用于＆＃34;模块＆＃34;你的申请。它更像是一个＆＃34;子应用程序＆＃34;你的申请。差异很重要。您的应用程序模块可能会共享模型，API或一些业务逻辑。尽管如此，责任的封装很重要，但会有一些联系。例如，几乎所有模块都可能使用类似EventDispatcher模块的东西。虽然隔离引擎是它自己的整个应用程序。虽然它可以使用来自主机应用程序的模型，但它不能使用来自不同隔离引擎的模型（至少没有黑客攻击，在某些情况下会有很多痛苦，并且通常很糟糕）导致糟糕设计的想法）。
因此，如果您尝试使用隔离引擎实现您的应用程序模块，您可能最终将所有模型存储在主/主机应用程序中，以便在您的实际上 - 子应用程序之间重复使用。可能与观点相同。也许还有资产。如果必须共享某些业务逻辑，它也可能最终会出现在主应用程序中。所以这基本上打败了整个目的。这就是为什么你应该为模块使用非隔离引擎的原因。虽然隔离引擎适用于 - 完全封装 - 子应用程序。例如，如果您想在主应用程序旁边拥有一个电子商务商店（spree gem就是这样）。
更多的企业示例是ERP系统。它可以有子应用程序，如：CRM，资源管理等（孤立的引擎）。这些子应用程序可以有自己的模块（不是隔离引擎）。
只是为了完整答案。作为一个孤立的引擎，我的意思是使用rails plugin new engine_name --mountable生成，而未隔离的引擎将使用rails plugin new engine_name --full生成。
声明：
也许在某些情况下你会想要采用不同的方式（可能是在实施某种神奇的宝石做一些神奇的事情时），但这取决于你解决它。通过这个答案，我只是说它应该适用于大多数应用程序。