我正在寻找以下问题的解决方案：
db_core应用程序仅包含小型核心系统的模型。 db_core应用程序将没有任何视图。
在db_core应用程序之上，我们将有一个管理界面。这将是一个可安装的引擎。管理界面将提供诸如javascripts，css，images等资产。
最后我们将有额外的可安装引擎;例如。 “blog”，“forum”，“身份验证”将安装在db_core应用程序上，所有这些可安装引擎应该具有与管理界面引擎相同的布局。
我有一个测试并运行db_core应用程序为资产提供服务，但我无法找到如何让另一个引擎为资产提供服务，因此db_core应用程序可以保持较小且没有任何资产和视图。 / p>
答案 0 :(得分：0)
我认为你真的是指一个孤立的引擎。请参阅Engine rdoc处的“隔离”您可以编写可安装但不隔离的引擎 - 这实际上意味着它有自己的路由，但在其他方面与普通的旧学校非隔离引擎相同。
但是由于这些原因，我已经停止将我的引擎写成孤立的。我很少想要一个实际上与主机应用程序完全隔离的引擎。我希望主机应用程序可以访问（并且能够覆盖自己的本地模板，通过命名相同但是在加载路径的早期位于其中的视图模板（如果不是布局））主机应用程序）和/或帮助方法，我希望主机应用程序有权访问并能够逐个方法地覆盖，和/或我希望在主机应用程序中使用的资产等。是，你可以编写一个生成器来复制它们，但是它们会在主机应用程序中“冻结”它们，并且可能是向前兼容性问题。
因此，就个人而言，我发现孤立的引擎会导致比他们解决的更多问题。我只是使用'普通'引擎，DIY以正确的方式隔离需要隔离的部分（例如模块名称空间控制器）。
路由/可安装相同。我不使用Rails'可安装的'引擎，但我也没有我的引擎通过自己的引擎/ config / routes.rb自动加载来自动添加路由到主机应用程序。相反，我有（不可安装的）引擎提供一个方法，主机应用程序可以放入它自己的routes.rb（路由对象作为arg传递），当被调用时将添加引擎需要的路由到应用程序。该方法可以使用参数来定制事物（仅添加一些路由而不添加其他路由，使用自定义路由命名空间，等等。）
我认为Rails 3通过“普通”引擎为您提供了所需的所有构建模块，使其能够以您想要的方式与应用程序集成。可安装/隔离的更高级抽象，为您修复了一堆这些选择，导致某些东西仅适用于某些用例。如果你真的想要一个完全隔离的子系统，那么肯定。如果你需要编写一个适用于任何Rack应用程序而不仅仅是Rails的引擎，那么你基本上需要将它作为一个完全独立的子系统运行（这就是设计最终的位置），但是你放弃了很多要做到这一点。 但是我开始相信它实际上并不是“从现在开始做引擎的最佳方式的未来”。
对于你想要做的事情，我认为让发动机隔离将会适得其反。让他们不孤立。但是接下来会有一些东西要弄清楚如何使你想要的隔离和路由使你的引擎表现出来（而不是你不想要的那种），这是真的 - 遗憾的是这些东西没有记录在案。