1. ホーム
  2. ruby-on-rails

[解決済み】RailsでOOデザイン。どこにものを置くか

2022-04-03 08:12:10

質問

私はRailsをとても楽しんでいて(一般的にRESTlessですが)、RubyがとてもOOであることを楽しんでいます。それでも、巨大なActiveRecordのサブクラスや巨大なコントローラを作る傾向はごく自然なことです(リソースごとにコントローラを使うとしても)。もし、より深いオブジェクトの世界を作るとしたら、クラス(とモジュール、でしょうか)はどこに置くのでしょうか?ビュー(ヘルパー自体にも?)、コントローラ、モデルについて聞いています。

Libは大丈夫で、私が見つけたのは 開発環境でリロードさせるための解決策をいくつか紹介します。 でも、もっといい方法があったら教えてほしいです。クラスが大きくなりすぎるのが本当に心配なんです。また、Engineについてはどうでしょうか、どのようにフィットするのでしょうか?

どのように解決するのか?

RailsはMVCという構造を提供しているので、最終的には自然に のみ モデル、ビュー、コントローラのコンテナが提供されています。初心者(そして一部の中級者)の典型的なイディオムは、アプリ内のすべてのロジックをモデル(データベースクラス)、コントローラ、またはビューに詰め込むというものです。

ある時、誰かが「fat-model, skinny-controller" パラダイム」を指摘すると、中級開発者は急いでコントローラから全てを取り出してモデルに放り込み、アプリケーションロジックの新しいゴミ箱となり始めます。

スキニーコントローラーは、実際、良いアイデアなのですが、その逆で、すべてをモデルに入れるのは、実はベストなプランではないのです。

Rubyでは、物事をよりモジュール化するために、いくつかの良いオプションがあります。かなりポピュラーなのは、モジュールを使うことです。 lib メソッドのグループを保持し、そのモジュールを適切なクラスに含めます。これは、複数のクラスで再利用したい機能のカテゴリがあり、その機能がまだ概念的にクラスと結びついている場合に役立ちます。

モジュールをクラスに取り込むと、そのメソッドはクラスのインスタンスメソッドになるので、結局は トン のメソッドが、複数のファイルにうまく整理されているだけです。

この解決策は、ある場合にはうまくいくのですが、他の場合には、コード内で ではなく モデル、ビュー、コントローラのいずれかを使用します。

このことを考える良い方法は、「単一責任の原則」(quot;single responsibility principle)で、クラスは単一(または少数)の事柄に責任を持つべきであるというものです。モデルは、アプリケーションからデータベースへのデータの永続化に責任を持ちます。コントローラは、リクエストを受け取り、実行可能なレスポンスを返すことに責任を持ちます。

これらのボックスにうまく収まらない概念(永続性、リクエスト/レスポンス管理)がある場合は、おそらく する をモデル化します。モデル化しないクラスは app/classes や他の場所に保存し、そのディレクトリをロードパスに追加することで実行できます。

config.load_paths << File.join(Rails.root, "app", "classes")

passenger や JRuby を使用している場合は、イーガー・ロード・パスにあなたのパスを追加することも必要でしょう。

config.eager_load_paths << File.join(Rails.root, "app", "classes")

要するに、Railsでこの質問をするようになったら、Rubyのスキルを上げて、Railsがデフォルトで提供するMVCクラスだけではないクラスのモデリングを始める時期が来たということです。

更新しました。 この回答は、Rails 2.x以降に適用されます。