Tag Archives: active record

捕获 ActiveRecord::RecordNotFound 输出 404 页面

Posted on 2013-09-12 by vvpick

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 种方式

Posted on 2013-03-05 by vvpick

当团队使用 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

Posted on 2013-03-04 by vvpick

有这么一个需求，一个在线音乐商店系统，我们暂且叫它’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