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() 方法来实现无模板的解决方案。而 Bram 法则（Bram’s Law）表示担心：如果一个软件越容易编写，那么实际上它会被实现得越糟糕。
……这正是我一直以来担心在 Rails 上发生的：在五年或者十年以后，你能找到的最差的工作将会是 Rails 的工作——你在维护一些非程序员写的代码，这些人发现 Rails 使得编程变得如此之简单，以至于他们根本不用知道他们在做些什么。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论