私は常に、ビジネスロジックはコントローラー内になければならず、コントローラーは「中間」部分であるため、静的のままであり、モデル/ビューはインターフェースを介してカプセル化する必要があると考えていました。そうすれば、他に何も影響を与えずにビジネスロジックを変更し、複数のモデル（データベース/ストレージのタイプごとに1つ）および多数のビュー（たとえば、異なるプラットフォーム用）をプログラムできます。
この質問で、ビジネスロジックを常にモデルに配置する必要があり、コントローラーがビューと深く関係していることを読みました。
私にとって、それは本当に意味をなさないし、別のデータベース/ストレージのタイプをサポートする手段を持ちたいと思うたびに、ビジネスロジックを含むモデル全体を書き直さなければならないことを意味します。
また、別のビューが必要な場合は、ビューとコントローラーの両方を書き換える必要があります。
誰かがそれがなぜであるか、または私がどこかで間違った場合に説明してもらえますか？
回答:
ElYusubovの答えの大部分は、ドメインロジックがモデルに入り、アプリケーションロジックがコントローラーに入るべきだと答えています。
2つの説明：
あなたとプログラミングの世界の大部分は、MVCパーツの役割を誤解しているようです。要するに、それらは：
モデル =ドメインロジック
ビュー =出力ロジック
コントローラー =入力ロジック
これは、モデルがビジネスロジック全体を担当することを意味します。画面上にウィジェットを描画する、プリンターを駆動する、HTMLとしてデータを出力する、HTTPリクエストを解析するなどに関連するものはモデルに属しません。
ただし、現代のいわゆる「MVC」フレームワークの多くは、実際にはMVCをまったく実行していないか、パーツに誤ったラベルを付けています。多くの場合、「モデル」と呼ばれるものはモデルの永続層であり、ビジネスロジックは「コントローラー」と呼ばれるものの中にあります。通常、実際のコントローラーは、ルーティングテーブルと、受信した入力を正しいビジネスプロセスにディスパッチするための個々の「コントローラー」のコードを備えた中央のエントリポイントです。これらのフレームワークが「ビュー」と呼ぶものは、実際にはすべてのビットです。プレゼンテーションロジック（ビュー）、入力の処理と検証（コントローラー）、およびビジネスロジック（モデル）です。実際のビューの大部分は、通常「テンプレート」と呼ばれます。
また、多層アーキテクチャについて読むこともできます。ここで、MVCは一方向（フローはController-> Model-> View）であり、Multi-Tierは双方向のもの（プレゼンテーション->ロジック->データ->ロジック->プレゼンテーション）であり、 MVCを実行するふりをするフレームワークは、実際には3層を実行し、プレゼンテーションを表示、ロジックをコントローラー、データをモデルに再ラベル付けします。
ビジネスロジックを完全に分離し、プレゼンテーションレイヤーインフラストラクチャから分離するには、アプリケーションサービスによってカプセル化する必要があります。MVCアーキテクチャは、プレゼンテーション層を実装する方法であり、すべてのビジネスロジックをこれらのアプリケーションサービスに委任し、そのスコープに留まる必要があります。ビューモデルは、ビューと表示または読み取りが必要なデータとの間のアダプターと考えてください。コントローラーは、ビジネスロジックをホストするビューモデル、ビュー、およびアプリケーションサービス間の相互作用を仲介します。
アプリケーションサービスは、ビジネスユースケースを実装し、MVCであろうとなかろうと、プレゼンテーション層から切り離されています。また、アプリケーションサービスは、トランザクションスクリプトまたはドメイン駆動設計をホストできます。
ストレージの場合、アプリケーションサービスは、リポジトリまたは永続化メカニズムの抽象化を参照できます。データアクセスをインターフェイスに抽象化することにより、さまざまな実装をサポートできます。通常、これらの抽象化は漏れやすく、実装間で部分的にのみ移植可能であり、完全な移植性を達成しようとする無駄な試みです。
更新
私の提案は、六角形のアーキテクチャに基づいています。六角形のアーキテクチャでは、ドメインモデル（ビジネスロジック）が中心になります。このコアは、ファサードとして機能するアプリケーションサービスによってカプセル化されます。アプリケーションサービスは、ドメインのユースケースに対応するメソッドを持つ単純なクラスです。アプリケーションサービスの詳細については、ドメイン駆動設計のサービスをご覧ください。コードサンプルにはPurchaseOrderService、購入ドメインのアプリケーションサービスであるが含まれています。（アプリケーションサービスは、ドメインドリブンデザインの使用を意味しないことに注意してください。）
六角形のアーキテクチャでは、MVCプレゼンテーションレイヤーは、ドメインモデル（ビジネスロジック）とGUIの間のアダプターです。ドメインモデルはプレゼンテーション層を認識しませんが、プレゼンテーション層はドメインモデルを認識します。
このソリューションには、ビジネスロジックをコントローラーに配置するソリューションよりも確かに可動部分があり、欠点と利点を比較検討する必要があります。複雑さを克服するために、ビジネスロジックをプレゼンテーションレイヤーから切り離したままにすることを好むため、提案する理由です。これは、アプリケーションが成長するにつれて重要になります。
ビジネスロジックの意味に依存します。モデルの内容に意味を与える「ロジック」は、モデル内にある必要があります。リンクされた質問では、最も投票数の多い回答が「ビジネスロジック」をデータに関連するものとして定義しているようです。これは、ビジネスのデータがビジネスであるという観点から理にかなっています！
私はかつてRailsの作成者（私が思うに）がモデルについて「ビジネスロジック」を入れずにまさにこれについて行っていた例を見ました。彼の例は、アプリの登録とログインのためのコントローラークラスとメソッドです。プレーンテキストで提供されたパスワードは、モデル（データベース）に挿入または照会される前に暗号化されました。
コントローラーロジックではなく、モデルに直接属するものの良い例は考えられません。
このモデルは、無数のデータストアへのインターフェイスとなり、移植性の問題を軽減できます。ここで、モデルインターフェースが実際に「コントローラー」であるかどうかについて、混乱を見つけることができます。
一般的に、コントローラーはモデルとビュー（アプリの要点）をリンクします。Cocoa開発では、コントローラーがXCode GUI（コントローラーオブジェクトとバインディング）を介して処理されるまで単純化できます。
MVCのGoFの「デザインパターン」セクション、大まかに引用：
クラスのMVCトライアドは、Smalltalk-80でユーザーインターフェイスを構築するために使用されます。モデルはアプリケーションオブジェクト、ビューは画面表示、コントローラーはUIがユーザー入力に反応する方法を定義します。MVCは、サブスクライブ/通知プロトコルを確立することにより、ビューとモデルを分離します。次の図は、モデルと3つのビューを示しています。簡単にするため、コントローラーは省略しました。
MVCはUIのすべてです。焦点はモデルとビュー-データの定義と表示にあります。「サブスクライブ/通知プロトコル」に注意してください-これがコントローラーの出番です。必要なビューをすべて作成できます。プロトコルに準拠している限り、モデルやコントローラーに触れる必要はありません。
特にWeb開発についてお話ししている場合、IMHOの多くの一般的なWebフレームワークは、MVCという用語とそのコンポーネント定義に関して高速で緩いものです。