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 使得编程变得如此之简单,以至于他们根本不用知道他们在做些什么。
评论