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