Tag Archives: active record

捕获 ActiveRecord::RecordNotFound 输出 404 页面

class ApplicationController < ActionController::Base protect_from_forgery with: :exception rescue_from ActiveRecord::RecordNotFound, with: :render_404 protected def render_404 render(file: “#{Rails.root}/public/404.html”, :layout => false, :status => 404) end end

Posted in ruby on rails | Tagged , , | Leave a comment

重构臃肿 ActiveRecord 模型的 7 种方式

当团队使用 Code Climate 来提高 Rails 程序的代码质量时,他们就会学习到如何防止模型慢慢变得臃肿。“胖模型( Fat models )” 在大应用中会导致维护问题。它仅仅比那种充斥着各种业务逻辑的凌乱的控制器好一点,但它们都违反了单一权责原则(SRP)。“任何有关用户做什么” 这种并不是单一权责。 刚开始, 单一权责很容易做到。 ActiveRecord 类只处理持久化,关联关系,并不管其它东西。但是,一点点地,他开始增长。原本应该只负责持久化的对象实际上也包含了其它的业务逻辑。所以,一两年后,你的 User 类超过了 500 行,有上百个公共方法。邪恶的回调问题开始出现。 随着你的程序越来越复杂(功能越来越多), 你的目标是在一些协调的,细小的封装对象(从更高层次来说就是模块)中传递信息,就像是在平底锅底抹面粉块一样。胖模型就像是你放入锅里面的一大块面团。你要将它重构成小块,均匀地分摊业务逻辑。不断地重复这个过程,最终你会得到一系列和谐工作在一起的简单对象。 你可能觉得: Rails 让正确实践面向对象编程(OOP)变困难了 我过去也是这样认为的。但是做了一些探索和实践之后,我发现 Rails (这个框架)完全没有阻止我们实践面向对象编程。其实是 Rails 的约定(convention)没有刻意强调这个,或者说是,它除了 ActiveRecord 模型能处理的情况外,缺乏管理更复杂的情况的约定。幸运的是,我们能够找到 Rails 缺少的, 如何应用基于面向对象原则的最佳实践。 不要从胖模型中抽离混入(Mixins) 为什么呢?我避免将一个大的 ActiveRecord 类里面的一部分方法放到某个关联类或者模块里面,然后将它们混入。我有一次听到这样的说法: Any application … Continue reading

Posted in ruby on rails | Tagged | Leave a comment

Rails中的Polymorphic Association

有这么一个需求,一个在线音乐商店系统,我们暂且叫它’online-store’,需要记录消费者对每首歌的评论,一个有经验的rails developer会很快地写出下面的代码: class Music has_many :comments end class Comment belongs_to :music end 对应的表结构如下: #musics: | id | integer| | name | varchar| | … | … | #comments: | id | integer| | text | varchar| | music_id| integer| 如果需要给music添加,查看评论,可以通过如下代码实现: … Continue reading

Posted in ruby on rails | Tagged , | Leave a comment