私は、toysユーザーがおもちゃで遊ぶために使用できるコントローラーを持っています。現在、claimメソッドはコントローラーレベルで実装されています（この回答が示唆しているように）。
ただし、実際には存在しないはずのロジックを要求することで、少し肥大化しています: 子供は既に 3 つのおもちゃを持っている場合、おもちゃを要求することはできず、別の子供が要求したおもちゃを要求することはできません。 . そのロジックの賢明な場所は (私の考えでは)childモデルにあります。
そうは言っても、これを行うと、toys#claimコントローラー アクションはchildモデルからメソッドを呼び出します。これはコードのにおい/悪い習慣ですか?
(これにはサービス オブジェクトを使用するよう提案する人がいると思います。もしそうなら、簡単なチュートリアルを教えてください。これに関する最近の RailsCast は、私には少し複雑すぎます。)
前もって感謝します！
一般的には (Rails 以外では)、臭いはまったくありません。実際、「モデル」と「コントローラー」の間の純粋な 1 対 1 のマッピングは臭いだと思います。
注:私は ROR 開発者ではありません。私は ROR の経験も、ROR の実装方法も知りません。しかし、私はデザイン パターンをよく理解しており、アプリケーション アーキテクチャも理解しています。とは言うものの：
1 対 1 のマッピングについて心配する代わりに、一歩下がってアプリケーションの構造について考えてください。
コントローラーは何をしているはずですか？一般的には、ユーザー アクションをアプリケーションにルーティングすることになっています。それは単なる配管ステップです。
では、モデル (レイヤー) は何をしているのでしょうか? 一般に、モデルは、アプリケーション内のすべてのビジネス ロジックを含むレイヤーです。データベースのやり取り、アクセス制御、ビジネス オペレーションなどを処理します。したがって、モデルは実際にはアプリケーションの大部分を占めます。
一方、ビューはプレゼンテーション層です。モデルレイヤーからデータを引き出して、すべてのレンダリングを処理する必要があります。
その理解に基づいて、モデル、ビュー、およびコントローラーは互いに独立して変化できる必要があります。一般に、コントローラーとビューの間にはかなりの 1 対 1 の関係があると思います。つまり、存在する各コントローラーには、ビューが表示されることが期待されます。ただし、ユーザーの操作がない場所にビューが存在する可能性があります。そのような場合、(ビューをレンダリングするために) コントローラーが必要な場合もあれば、アーキテクチャによっては不要な場合もあります。
ただし、モデル層の小さな部分である「モデル クラス」(下位モデル機能のプロキシまたはアダプターとして機能する) は、コントローラーまたはビューと 1:1 である場合とそうでない場合があります。たとえば、複数のモデルからデータを取得するビューがあるとします。複数のモデルに作用するコントローラーを持つことができます。
ここで一歩下がって、コントローラーが複数のモデルに作用する必要がある場合は、その操作を抽象化する新しいモデルを作成すると言うことができます。時にはそれが正しいことです。そうでない場合もあります。それはすべて、関連する特定の操作と関係に要約されます...
結局のところ、ここには「正しい」も「間違っている」もありません。実際には、アプリケーションを構築するときに行う必要がある設計上の決定になります。アプリケーションで意味がある限り、「におい」コンポーネントについてはあまり心配しません...