最近一段时间，我一直在旁观大家对引擎、组件和更强大的插件充满热情。这对每个人来说都是五味杂陈的。一方面，我很高兴看到大家如此兴奋，并开始梦想更大更美好的事物。这是激情澎湃的表现，非常棒。

另一方面，我认为这些开发基本上是高级组件的别名。你们都知道 我对此有何感受。简单来说，高级组件实际上是海市蜃楼：一旦它们变得有趣，所需的适配工作就会比从头做起还多。

但我开始感到疑惑，当我听说“依赖于可以被另一个引擎替换的其他引擎的引擎”。即使插件依赖项也极其接近我不太适合 Rails 的考虑范围。这仅仅是因为它鼓励我发现不健康的开发风格。

因此，这并不是对技术优点或引擎或同类产品的实现进行批评。这仅仅因为担心它们会分散注意力，担心它们会出现要，并反过来会将 Salted Hash Login 混乱提升到新的标准化水平。

Rails 的重点是让简单的东西变得非常容易，以至于您无需对其进行抽象。它的目标是轻而易举地创建登录、访问控制、内容管理等所有业务逻辑组件，以至于您会珍视自己的特定应用程序解决方案，而不是渴望一个真正的登录系统。

那么，我所说的呢？是应该阻止引擎吗？当然不是。我的意思是，Rails 将继续通过内核中包含的内容发出信号，表明这只是辅助项目。它满足某些人某些需求，并且这样很好。但 Rails 的目标是创造不需要或强烈期望它们的世界。显然，我们还没有完全达到那个地步。

进入那个世界的方法之一，就是让新人更好地了解通用模式。回答问题“如果引擎和组件没用，那么请向我展示如何做到！”。这呼吁所有专家。帮助我们传播良好的模式。制作视频，撰写教程，帮助 #rubyonrails 上的新手，回复邮件列表中的请求。

如果您有一个引擎的出色构想，或总体上一个高级别的组件，请考虑一下这个问题：是否有办法以独立插件的形式抽象一个更小的功能切面，然后将它与一个模式一同发布，来描述如何像组件在软件中那样使用它？我认为您大多会发现这是正确的。

注意：引擎做法的创建者 James Adam 已经在邮件列表上发表过 一篇很棒的帖子，介绍他如何在公司内部使用引擎。这是一个非常酷的使用方法。高级别组件唯一存在问题的原因在于要让它们通用。