这个结果对实际项目感觉没什么意义,毕竟线上项目可不是运行的 hello world 想像一下复杂的线上项目基于 rack,用纯净 ruby 编写,酸爽程度不论,其实还是要写出另一个不会比 rails 更好的框架来。
基于 rack 写的不会比 rails 更好,但是可以做分布式事务处理,公司业务有新的需求讨论完了就直接写代码,不会跟老板硬杠 rails 这个版本还暂不支持这个功能,下个版本要等到 6 个月以后才发布,也不会看到一堆“warning @rails/webpacker > postcss-preset-env > postcss-color-gray > postcss-values-parser”心烦意燥
事务实现一般放在在 service 层
关于 rails 的分层 可以参考 https://ruby-china.org/topics/41603
当然 rails 框架不需要支持 因为标配的 rails 是类似 20 年前 struts/ Webwork 那样处理 form 表单的,配置一下表单验证和跳转流程 XXmodel.save 然后数据库里就有记录了 地铁终点站就是到 M 就下车了
如果是面向服务的应用,发现需要的没有 (或者跟老板硬杠耐心等待 6 个月以后的下一版,一切都完美了),不需要的一大堆,去掉不需要的一要花时间,二是提心吊担上线以后不知道什么地方会出幺蛾子。
Rails 增加一个 service 层就是新建一个文件夹那么容易。Rails 的底层就是 Rack,所以我很好奇有什么是 Rack 能做 Rails 不能做的。
Rails 汇聚了大半个 Ruby 社区的智慧,因为一点点问题就自建框架在熟悉 Rails 的人看来只是因小失大,不过这也是个人自由了。