7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
あけましておめでとうございます。 大晦日は実家でプログレ聞きながらコード書いてました。 今さらながら Heldon の Stand by とか聞いてたんですが、Tangerine Dream を思わせるミニマルなシンセサイザーの反復と、リシャール・ピナスによるロバート・フリップばりの暴力的なギターソロが絡みあっており、大変良いですね。 作ったもの また説明長くなりそうなので、はじめに作ったものの紹介です。 dee dee-rails この Dee というのが DI コンテナの本体です。 名前は Ozzy Osbourne ソロ 1st Blizzard of Ozz におけるランディ・ローズのギター曲からです。 50 秒と短く、メタルアルバムの中にあってクラシック風の静かなギター曲ですが、同時にアルバムから欠かせない存在感を放つ名曲です。 何が言いたいかというと、Dee はコンパクトな実装
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている！」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
最近、いわゆるRailsの古めのバージョンで書かれたプチレガシーな感じのアプリケーションを触っていて思ったこと。 ちなみに、この話題は多くの人にとって大分今更感のある内容なので、逆にこれを読んで「今更だなぁ、そんなのとっくに結論出てるでしょ」と思わない人はヤバい。 めんどくさいのでデータ永続化を行うためのミドルウェアはMySQLという前提で書く。 単純に言うと、いわゆるRailsアプリのMVCではMがActiveRecordかなんかを継承していて、そのまま作るとModelとtableが一対一対応になってしまう これだと、どのModelにも属さないようなビジネスロジックを置くべき場所がどこなのかよくわからない 「どのModelにも属さないようなビジネスロジックなんてないでしょ！」「どのModelにも属さないビジネスロジックがある時点で設計おかしいでしょ！」と思った人は幸福である。頭が。 ちな
Takuto Wada @t_wada @june29 伝統的には「関心事」ですかね…? Crosscutting Concern とか Core Concern とかの訳語に使われることが多いです。 2013-01-23 14:23:42 OHWADA Jun🚿 @june29 @t_wada 反応ありがとうございます！なんとなくわかってきたような気もしますが、なぜ ActiveSupport の中のこの Module が Concern という名前なのかは、まだ自分の言葉で説明できるほど腑に落ちてきていません…！引き続き考えてみます！ 2013-01-23 14:29:38
FrogApps 技術ブログ始めました！ RailsやiOS、HTML5の情報を発信中!! → http://qiita.com/teams/frogapps Railsでアプリを作っていると、app/models/以下にあるモデルファイルの行数が非常に長くなることになります。 そこでincludeメソッドを使ってモデルファイルを機能毎に分割してみましょう。 ファインダー関係のメソッドだけを、user/finder.rbに切り出します。 このときクラスメソッド関係は通常の定義方法が異なります。 クラスメソッドの定義は、ClassMethodsモジュールの中で行う様にします。 has_many, belongs_toなどのクラスメソッドの実行は、self.includedの中でbase.has_manyの様にして呼び出します。
メリークリスマス！ PHP Advent Calendarもいよいよ24日目に突入です。 昨日はxhprofについてでしたね。僕もパフォーマンスチューニングの際に使っています。手軽に利用できるのでお勧めです。 さて、このエントリーでは表題の通りMVCについて書かせていただきます。これは、PHPカンファレンス2012&WordCamp Tokyo2012合同LT大会で発表した「やはりお前らのMVCは間違っている」で煽るだけだったこの問題をきちんと解説するものです。 この発表資料を公開するとPHPの枠を超えて広く閲覧いただき*1、また多くの方から突っ込みを戴きました。「LTだから」と言って逃げていた回答をして、気持ち新たに新年を迎えようと思います。 MVCとはなんなのか 間違いを指摘する前にMVCがそもそもどういうアーキテクチャであるのかを確認しなければいけません。 MVCは1970年代にパロ
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く