背景: アプリ a、b があり、この同じアプリケーションにさらにアプリを追加する予定です。アプリは十分に類似しており、多くのビュー、アセット、およびアクションを共有できます。現在、a,b は単一の Rails アプリ (2.3.10) に住んでいます。cは、このRailsアプリにもあるほど十分に似ています。
問題: この 1 つのアプリにさらにアプリを追加し続けると、ケース ロジックが多すぎて、すぐにアプリを維持するのが困難になります。また、名前空間の問題が発生する可能性もあります。ただし、アプリは機能とレイアウトが非常に似ているため、1 つのアプリにまとめて維持することも理にかなっています (サイトの外観/機能の約 50% が共有されるため)。
私たちがやろうとしているのは、これをできるだけきれいに保つことです。これにより、複数のチームが作業しやすく、保守しやすくなります。
私たちが考えたこと/試みていること: エンジン。各アプリをエンジンにします。これにより、ルートをドメインに基づくことができます。また、特定のアプリのコントローラー、モデル、およびビューを引き出すこともできます。アプリをすぐに再利用することはないため、このソリューションは理想的ではないようです。また、ルートでホストを明示的に指定することは正しくないようです。
スキニング/テーマ。認証ロジックはアプリ間で異なります。各ユーザー モデルは異なります。したがって、これはスキンの問題だけではありません。
app/view で、sitea ビューのフォルダー sitea、siteb ビューの siteb などを追加します。コントローラーとモデルについても同じことを行います。これはまだかなり厄介で、命名規則に従わなかったため、Rails ではうまく機能せず、多くのコードが乱雑になりました。
Railsアプリをもう一つ作っています。2 つのアプリが同一である場合、同じコントローラーまたはビューを維持したくありませんでした。
私たちがやりたいことは、アプリがホストに基づいてコントローラーをインテリジェントに使用できるようにすることです。したがって、各アプリにはセッション コントローラーがあり、おそらく共有ロジック用の親セッション コントローラーがあります (現在は必要ありません)。これらのセッション コントローラーのそれぞれで、その特定のアプリの認証を処理します。したがって、ドメインが a.mysite.com の場合、アプリ a のセッション コントローラーを使用し、アプリ a のビュー、モデル、コントローラーを使用することを認識します。また、ドメインが b.mysite の場合、b のセッション コントローラーを使用します。また、a のユーザー モデルと b のユーザー モデルがあり、これもドメインによって決定されます。
この状況で誰か提案や経験がありますか? そして理想的には、Rails 3 への更新は現在オプションではないため、Rails 2.3.x を使用します。