質問のために、2 つのユーザー タイプがあるとしましょう: type1& type2. 表示されているユーザーのタイプに応じて、Rails でコントローラー/モジュールを使用したいと考えています。例えば：
User(id: 1, type: 'type1')hastype1とUser(id: 2, type: 'type2')hasの場合、次type2のようになります。
/users/1
Type1::UsersController を選択します。そして行く：
/users/2
Type2::UsersController を選択します。
これにより、タイプごとに異なるコントローラーとビューを使用できるようになります。
type注: URL に を表示したくありません。動的にしたいのです。
これは可能ですが、Rails の方法に対して (おそらく) 不必要な戦いをたくさん行うことになります。おそらくかなりの共有ロジック（保存、削除、作成など）があるため、1つのコントローラーが必要になると思います。
あなたの質問に答えるには (回答ではなく推奨事項を残すのが嫌いなので)、Routing を拡張するモジュールを作成する必要があります。これにより、カスタム マッチングが可能になります。そこから、チェックを行い、適切にルーティングできます。 ここに例があります。
とはいえ、より良いルート (しゃれは意図されていません) は、ビューを選択できる集中型メソッドを持つ 1 つのコントローラーを用意することです。
def find_view view_name
"#{view_name}#{@user.type}"
end
そのため、render find_view('new') を呼び出すと、「new-type1」という名前のビューをレンダリングしようとします。タイプ 1 のユーザー固有のロジックをすべてそのビューに配置できます。ユーザー タイプ 2 についても同様です。
繰り返しますが、ユーザー コードには多くの重複があると思われるため、この find_view メソッドをヘルパー クラスにプッシュして、ビューから呼び出すことができ、ユーザー タイプに基づいて特定のパーシャルをレンダリングするなどの操作を行うことができます。 . これにより、より多くのコードを再利用できるようになりますが、これは決して悪いことではありません。
単一のコントローラーを使用することに頭を悩ませると、ユーザー タイプ固有のコードをさまざまな手段にプッシュする簡単な方法がいくつかあります。これらはユーザーの種類に基づいて動的に呼び出されますが、他にもあると確信しています (おそらくより良いもの)。しかし、これらすべてに 1 つの重要な共通点があります。1 つのルート、1 つのコントローラーで Rails に道を譲ることに屈した場合、Rails との戦いが大幅に減り、コードの重複も少なくなります。
頑張ってください。