Rails Rails 应用在架构设计上的不足

chenge · 2016年11月16日 · 最后由 zzz6519003 回复于 2019年07月12日 · 3353 次阅读

这个图很好地说明了 Rails 应用在架构设计上的不足。

图片来自:http://railshurts.com/principles/

共收到 16 条回复

那么,这个作者想要推销什么呢?

这个作者应该会欣赏 micro services

#1 楼 @Rei 他提到了 Hanami,还有一些:

“Or you can rely on tools. You can start using tools with modularity ideas built in, like Lotus or ROM. Of course, there is a less radical way. You don't always have the luxury of starting from scratch, but you can tweak Rails to provide some complexity management. Some of of the tools that may help you:

  • collectiveidea/interactor
  • apotonick/trailblazer, apotonick/cells
  • makandra/active_type”

Rails 的架构在几年前还是不错的,但是现在时代变了,整个架构思想和团队组织也变了.以及不适合 Rails 这种全包的架构了. 没有可伸缩性. 但是作为独立开发者,还是 One.

如果觉得 Rails 笨重,Sinatra+ActiveRecord 也是一个很好的选择,参见拙作:Sinatra + ActiveRecord = Really Lean Startup?

没有觉得 Rails 跟图上画的一样,跟业务逻辑交织在一起,完全就是个错误的论断。

刚看了下他的一些文字,,他连 Convention over Configuration 都可以站出来反对,说这会 “增加耦合”,实在是无语。估计这位同学是 J2EE 的卫道士——不依赖任何外部库,所有东西都手写,方法都是静态的,最符合其要求。

有点意思,我觉得 ActiveRecord 特别是其中的 callback, 还有 controller 里各种 filter 已经成为了我的噩梦了, 这些东西把我虐的不要不要的

大致看了几点, 作者想法就是写了个文章刷下存在感无它.

软件中任何的观点要结合适宜场景去做就好, 不做会乱过度也会乱, 遵循 Rails 的原则也是这样的.

我没理解错他意义的话: 比如讨论 DRY 他的观点就在疑惑于何时做这事, 没有一个合理, 再一个减少重复时可能引入抽象等导致代码 复杂度上升. 实际中的话应当是这样, 当你发现一直重复类似方法时先抽方法,有业务需要再抽象, 怎么弄就看具体需要, 实际也容易搞出恶心一笔, 当把一个共用的东西搞得太恶心, 显然就应该拆分开.

天下合久分, 分久必合, 我觉得这个做法是最好处理 DRY 的困惑.

#6 楼 @Xenofex 他是先肯定了 CoC 的,只是说过度使用的问题。Rails 学习难度比较大也是这个原因,有很多隐含的设定。类似于所谓的潜规则,长期来说还是明规则比较好。

Conventions over configurations What could be wrong with conventions? We should praise Rails for giving us naming convention about database stuff, that makes sense.

But some developers take it too literally and go mad with it. They introduce their own extra conventions. And they are usually implemented with hardly readable metaprogramming code.

The bad thing about conventions is that they are implicit. So if there's too many of them, it can be hard to remember why everything is done in a way it is done.

Even default conventions might become too tight for you when your app grows. So just remember that the price of convention is flexibility.

这个文章就是在哗众取宠,强行挑毛病,忽悠小白说你们不要用 rails 这很不 oop

我很乐意承认 Rails 可能会存在一些问题,不过这个作者的论点有点断章取义了

比如 DRY

因为 DRY = Abstraction
并且 Duplication > Wrong Abstraction
所以 Duplication > DRY

丝毫不考虑Right Abstraction的情况

再说 KISS 他说的一大堆如果建立在 Rails 经常出现莫名其妙不可调试的错误,且 Rails core team 水平不高的情况下,不过我认为这不符合现实。

再看这个网站的首页 slogan

The goal of this project is to help developers stop suffering while they are working with Ruby on Rails

如果把他的反对 Rails 的地方都去掉然后再来用 Rails,嗯,大家可以想象一下。

#9 楼 @chenge 是我说错了,我本来应该指的是他说 Don't Repeat Yourself 会增加耦合度。至于 Convention over Configuration 他本来意见也比较弱

@darkbaby123 俺只有一个好字奉上

lilijreey 回复

可伸缩性体现在哪

chenge 回复

个人的 conventions 比如?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册