肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）

更新情報: 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

[j5ik2o]

これ悪くないんだけど appの中にレイヤーがごちゃまぜ感がすごいので まず application, domain, infrastructureに分割統治すべきだよね。低結合高凝集ってそういうことだよねーってことで。

[rightgo09]

参考になった

[justgg]

「ミックスインよりも継承で」は誤訳かと。Prefer composition to inheritance→継承よりコンポジション。/　modelsの下に階層作って置きたいところ。

[carolina04]

“表示にしか使わないようなロジックが必要な場合、それはモデルに置くべきではありません。「仮にアプリケーションのUIががらりと変わったら(たとえば音声駆動UIになったとしたら)、その時にもこれをモデルに”

[youko03]

これどの本に載ってるんだ

[ttanimichi]

View Object の解説が詳しく書いてあった

[yimajo]

だいぶ古い記事、Service Objectは今で言うUse Caseと同じパターンと言えそう

[iR3]

ふむふむ

[d4-1977]

なるほど。やっていく

[iox]

formobjectはよい

[kent-where-the-light-is]

““app/concerns ディレクトリを使っているようなアプリケーションって、だいたい後から頭痛の種になる(=concerning)んだよね””

[masutaka26]

３年前の記事。良いところも悪いところもある。

[kenta-yam-124]

“コールバック”

[h5y1m141]

"本記事で紹介したテクニックを一部だけでも適用して、自分のアプリケーションのドメインモデルに固まっているロジックを分散させることができれば、アプリケーションのメンテナンスはずっと容易になるでしょう"

[shiwork]

肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) | TechRacho こういう資料ってもうちょい無いかなcookpadとか

[hamichamp]

メモ

[criff]

“ あるブログ投稿にコメントが付くと誰かのFacebookウォールに自動的に投稿されるようにしたとします。この場合、このロジック自体をCommentクラスにハードコードしなければならないということにはなりません。コールバ

[JHashimoto]

“ActiveRecordクラスは永続性と関連付けを扱うものであり、それ以外のものではありません。" "永続性について本質的に責任を持つオブジェクトは、やがて事実上ビジネスロジックも持つようになるのです。”

[to4iki]

“OOP”

[kkabetani]

日本語あった。ありがたい

[tomity]

これどうなん？

[anconium]

あとよむ

[Hash]

なるほど. accept nested attributes forの代わりにfromオブジェクト作るのとかよさそう

[ryonext]

これ会社のメンバーと共有して実践しよう

[joker1007]

既に読んでるけど日本語にしてくれたのありがたい。

[lEDfm4UE]

refactoring

[igrep]

参考にする、かも。

[nemoba]

Rails限らず、MVCのFatModelに結構汎用的に使える

[kakuhen1rfeverheiten]

リファクタリング

[qaz76]

_φ(･_･

[madarax11]

肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳) - TechRacho