42

controllersデフォルトのディレクトリ ( /modelsなど)のいずれにも収まらない非標準の Ruby ファイルを Rails アプリのどこに配置するかについて、ベスト プラクティスがあるかどうか疑問に思っています。

コントローラー/モデルなどで使用されるクラスについて話していますが、Rails の基本クラスのサブクラスではありません。モデルを軽量化するためにモデルから抽出された機能を含むクラス。モデルのように見えるが AR モデルではないもの、「サービス」のように見えるもの、その中間またはその他のものなどがあります。

いくつかのランダムな例:

  • Facebookなどを介したパスワードによる認証を処理する「戦略」クラス。
  • パラメータをカプセル化する「XParams」オブジェクト、またはパラメータの処理を処理して複雑なアクションを実行し、最終的にいくつかの AR モデルを作成する「XCreator」オブジェクト
  • 外部 API にリクエストを送信するか、それらのリクエストとレスポンスをカプセル化するクラス
  • 実際の AR モデルの代わりに使用できる偽のモデル (例: ゲスト ユーザー)
  • ジョブの再要求
  • Redis から情報を保存および読み取るクラス
  • データの処理、レポートの生成などの特定のアクションを実行し、Resque ジョブまたは rake タスクから呼び出されるクラス

私は今、これらをかなりたくさん持っています。そのうちのいくつかは追加さlibれ、最終的にランダムなクラスとモジュールの山になり、いくつかは に忍び込みますapp/models。どうにかして整理したいのですが、どこから手をつけてよいかわかりません。

AR モデルだけが に入る必要がありapp/modelsますか? それとも、ドメインやヘルパー モデルを配置しても問題ありませんか? 何かがモデルであるかどうかをどのように判断しますか?

に収まらないものはすべて に入るapp必要がありlibますか? または、いくつかの新しいカスタム サブディレクトリを に追加する必要がありappますか? サブディレクトリは何ですか? カスタム クラスを分割するにはどうすればよいですか?

プロジェクトでこれをどのように処理しますか? すべてのプロジェクトが少しずつ異なることは知っていますが、いくつかの類似点があるはずです。

4

5 に答える 5

15

良い質問です。具体的な答えはありません

しかし、この投稿をチェックすることをお勧めします - http://blog.codeclimate.com/blog/2012/02/07/what-c​​ode -goes-in-the-lib-directory/ - すべてのコメントを必ず読んでください

現在のプロジェクトでは、アプリ/モデルの下に大量の非 ActiveRecord オブジェクトがあります。機能しますが、理想的ではありません。「再利用可能な」非アプリケーション固有のコードを lib の下に置きます。

私がサイドプロジェクトで試した他の選択肢(たとえば、コマンドオブジェクトがたくさんあるとします)レールは、アプリの下の名前空間に関しては面倒です。デフォルトですべてを同じ名前空間にロードします

app/
  commands/
    products/create_command.rb         # Products::CreateCommand
    products/update_price_command.rb   # Products::UpdatePriceCommand

代わりに、src または app_name ディレクトリの下の rails 以外のすべて

app/
  src/
    commands/
      create_product.rb         # Commands::CreateProduct
      update_product_price.rb   # Commands::UpdateProductPrice

私はこれに対する良い解決策に出くわしていません。理想的には2番目の方が優れていますが、アプリの下に追加のディレクトリを持たない方がいいでしょう。そうすれば、アプリを開いてコントローラー、コマンド、モデルなどを見ることができます...

于 2013-03-07T00:59:30.990 に答える
9

さまざまなユースケースに触れますが、この部分は「正しい」答えに最も近いと思います。

私は今これらをかなりたくさん持っています、それらのいくつかはlibに追加され、それはランダムなクラスとモジュールの山として終わり、いくつかはアプリ/モデルに忍び込みます。なんとか整理したいのですが、どこから始めたらいいのかわかりません。

それは私の本ではほとんど正しいです。あなたが言及していないことの1つは、さまざまな部分を別々の宝石に抽出することです。外部サービスと通信するクラスは、十分に一般的である場合の戦略クラスと同様に、抽出の優れた候補です。独自のgemサーバーを実行するのは難しくないため、これらはプライベートにすることができ、RORアプリ全体で明らかに再利用できます。

最後に、そして最も具体的には、私がlib/jobsに詰め込むジョブを要求します。

私の親指のルールは、それが何らかのモデルである場合、それはに入るということapp/modelsです。そうでない場合は、おそらくlibそのサブディレクトリまたはその適切な名前のサブディレクトリ、たとえば、、などに属しlib/jobsます。lib/extensionslib/external

于 2013-03-07T00:45:52.180 に答える
3

モデルクラス(STIサブクラスなど)をに配置しapps/modelsます。他のクラスをlib配置するのに最適な場所のように思われるので、に配置します。どこを見ればいいのかわかりやすいです。また、モデルクラスがすべて1つの場所にあるため、テストをグループ化するのも簡単です。

慣例的に、私はヘルパークラスをに入れるのが嫌いですapp/models。プレゼンタークラスの場合は、に属しますapp/helpers。そうでない場合は、彼らlibにとって最適な場所のようです。

于 2013-03-07T00:44:43.263 に答える
3

興味がある場合は、これについてのフォローアップ記事を少し後で書き、見つけたことをまとめました

于 2015-04-08T12:14:14.183 に答える
1

多くの場合、私のクラスはlib、サブディレクトリと同じ名前のモジュールがそれらを含める責任があるサブディレクトリに侵入します。(オートローダーに関しては、Railsはファイル名とクラス名について非常に扱いにくいです。)

もう1つのオプションは、各モジュールを独自のgemにカプセル化してから、Gemfileを介してgemを参照することです。これにより、プロジェクト間でのコード共有が可能になります。

于 2013-03-07T00:45:42.707 に答える