Ruby on Rails 为什么成为最炙手可热的 Web 框架？到底是因为它引入了许多全新的革命性理念？或者仅仅是因为它为早已众所周知的设计实践带来更为优秀的实现？这正是 Giles Bowkett 所问的第一个问题。他通过比较了 Rails 的视图 / 控制器模式和 Seaside 的组件及渲染方法，向大家阐述了自己的想法。将 Rails 的视图 / 控制器替换成与 Seaside 更为相似的方式，是否值得呢？
Giles 着重指出这种架构的优点（如集中管理）和缺点（如毫无意义的 URL）：
难道你不能模拟 Seaside 的组件化模式么？你可以把 Rails 的控制器和视图替换成包含带内建渲染方法（built-in render methods）对象的 Builder 模板，而那些内建的渲染方法可以调用其它 Builder 模板。这当然行得通，事实上，你基本能实现除了 Continuations 之外的所有东西。但问题是，如果你没有 Seaside 的 Session 管理，这样做是否值得？而且在除了 Smalltalk 之外的语言中 Session 管理会不会变成一场噩梦？这里的观点是，Rails 的模板系统是一个又大又臃肿又臭气熏人的大洋葱。最后，事实上我们为 Seaside 风格的开发提出了一个可能比 Rails 更好的设计方案，而且保留所有 Ruby 强于 Squeak 的优点——更简便的 DB/Unix 集成，更多开发人员，等等。
文章收到不少评论，其中 Assaf Arkin 友善地指出如何使用 Rails 中的 capture() 方法来实现无模板的解决方案。而 Ramon Leon</a>和 Giles Bowkett 则更进一步，他们展望了一个在 Ruby on Rails 上实现 Seaside 的最佳组合（Best of Breed）解决方案。</p> <p>尽管他主意很有创意，Giles Bowkett 是一个名副其实的 Rails 狂热爱好者。简化开发是 Rails 最宝贵的资产，但它是否会成为某种不足呢？这是 Giles Bowkett 问到的第二个问题，他对 <a href=">Bram 法则（Bram's Law）表示担心：如果一个软件越容易编写，那么实际上它会被实现得越糟糕。
……这正是我一直以来担心在 Rails 上发生的：在五年或者十年以后，你能找到的最差的工作将会是 Rails 的工作——你在维护一些非程序员写的代码，这些人发现 Rails 使得编程变得如此之简单，以至于他们根本不用知道他们在做些什么。
评论