2012-03-16 15 views
2

私は同じコードの多くを共有するいくつかのモデルを持っています。 モデルの共通コードをRails 3に入れる正しい場所はどこですか?私はイニシャライザの使用を検討してきましたが、私はここでベストプラクティスに固執していません。RailsでモデルをDRYするには?

+1

私はあなたがモジュールを作り、それをライブラリに入れると思います。しかし、おそらくあなたの状況から具体的な例を挙げるべきです。 –

+0

私はイニシャライザが適切なパスではないと思っています - システムのブートストラップ、設定の設定などに必要なコードです。 'application.rb'(そしてその従兄弟' application_controller.rb')がそこにあり、自動的に含まれています共有モデル(およびコントローラ)メソッドをグローバルにアクセス可能にする。しかし、私はKenとck3gに同意します。もしあなたが汎用ユーティリティをいくつかのコンテキストで使用しているなら、 'lib'がそれらを置く場所です。 1つの例外は、サブクラス化の真の例です(例えば、Animモデル、Dog、Catサブクラスがそれぞれ 'sound'メソッドを実装しているか、またはそのようなフィクション:-) –

答えて

1

同様のコードをモジュールに入れて、モデルに組み込むことができます。例えば、モジュールはlib/models/に置くことができます。

2

おそらく、多くの人がコードをモジュールに入れて、それらのクラスに含めると言ってこれに答えます。それは間違っていないし、あなたがしたいことに完璧かもしれませんが、それはあなたの唯一の選択肢ではありません。上で述べたKenのように、本当にコンテキストに依存するので、具体的な例を投稿するべきです。

私の経験では、これらの共有メソッドが実際には別のクラスに属していることがあります。モジュールの代わりに別のクラスを使用すると、モデルのコンテキストに依存することなく、それらの共有メソッドだけを簡単にテストできるように、モジュールをよりよく分離することができます。私は一つのアプローチが他のアプローチよりも優れていると言っているわけではありませんが、それはオプションであり、あなたの共通の方法を新しい方法で考えさせるかもしれません。

+0

この場合、私は非常に簡単に特定の例を投稿できません。要するに、4つのモデルは、データをどのように取得するかという観点から、同じ機能とコードの多くを共有しています。基本的には、アプリはさまざまな場所からデータを取得しています。私は、モデル全体で同様の機能や同一の機能を維持する必要がないように、DRYをしたいと思っています。最終的にはこれらのモデルはこのアプリケーションに特化しており、全体のアプリケーションをサブアプリケーションに抽象化すると、これらのモデルは常にこの特定のサブアプリケーションに固有のものになります。 – ylluminate

1

IMO lib /は、実際にはアプリケーションの外部にあるライブラリ用です - ベンダー/とほとんど同じです。また、開発時に自動ロードされません。

すべてのアプリケーションロジックは、実際にapp /にある必要があります。私は時には、共有モデル/コントローラコードのアプリ/関心事を使用します - またはアプリ/モデル/共有/

ビーリングトン氏によると、モジュールが適切な方法であるかどうか再考する価値もあります。インジェクションしようとしている機能を検討し、別のクラスが適切かどうかを検討してください。

+2

libフォルダは、autoload_pathsに追加しない限り、他の環境でも自動ロードされません。あなたの答えに具体的に言及して以来、私はこれを書いています。 – AMIT

関連する問題