私の理解では、MVC はプレゼンテーション層をビジネスおよびデータ層から分離する方法です。私はこれを正しく理解していますか？もしそうなら、MVC はビジネス ロジックをプレゼンテーションから完全に分離する必要があります。
だから私には、JavaScript（またはjquery）がクライアント側のロジックの一部を引き継ぐため、何らかの形でMVC設計に違反しているように思えますね。モデル = データ層、コントローラー = ビジネス層、ビュー = プレゼンテーション層ですか? 私は全体の概念を誤解していると思います。
あなたはMVCについて十分に理解しているようです。問題は、2 つの異なる潜在的な MVC 構造を 1 つの同じものとして見ていることです。サーバーでは、データ モデル、コントローラー、およびビューを使用できます。クライアント側では、データ モデル、コントローラー、およびビューを使用することもできます。クライアント側の JavaScript を MVC として見たい場合、jQuery は、ビュー コントローラーがビュー (DOM) を操作するために使用できる単なるユーティリティです。
簡単に言えば、クライアント側は常にビューだけである必要はありません。たとえば、Backbone などの Web アプリケーション クライアント側フレームワークを使用する場合、モデル、ビュー、およびコントローラーをすべてクライアント側に配置し、サーバー上の別の SEPARATE MVC 構造と通信できます。
あなたが説明することは、実際には多くの実装に課題をもたらします。ASP.NET MVC フレームワークなどのフレームワークは、中間層のビジネス ロジック (主にフォーム フィールドの検証規則) に基づいて JavaScript を UI に自動レンダリングしようと試みてきました。しかし、ロジックを繰り返さない、真に魅力的な JavaScript ユーザー エクスペリエンスを実現するにはほど遠いものです。
個人的には、JavaScript は純粋に UI の問題だと考えています。アプリケーションは、すべてのロジックを内部的に処理します。UI の一部としての JavaScript は、そのロジックの一部を複製する場合がありますが、厳密には UI の目的のみです。ユーザーが JavaScript を無効にしている場合、アプリケーションは正常に機能している状態に戻る必要があることに注意してください。つまり、サーバー側 (中間層) のコードを使用してジョブを実行する必要があります。JavaScript が行ったことは、UI レイヤーにより豊富なユーザー エクスペリエンスを追加したことだけです。
この問題の原因は JavaScript だけではありません。中間層に、オブジェクトの有効または無効を定義する多数の検証ロジックがあるとします。これらのオブジェクトをデータベース (UI と同じようにアプリケーションの周辺にあります) に保存すると、そのデータベースにも重複した検証ロジックが含まれていませんか? null 非許容フィールドなど。
おめでとう！あなたの MVC に対する理解は完全に間違っています。n層アーキテクチャとは何の関係もありません（これはあなたが混同しているようです）。
MVC の核となる考え方は、関心の分離です。これは、アプリケーションを 2 つの主要なレイヤーに分割することによって使用されます。
次に、プレゼンテーションは、コントローラー (ユーザー入力を処理するため) とビュー (応答を処理するため) にさらに分割されます。
Web アプリケーションに適用すると、サーバー側にのみ MVC (または MVC のような) 構造を持つか、より大規模で複雑なアプリケーションの場合は、フロントエンドとバックエンドの両方に個別の MVC トライアドを使用します。
また、アプリケーションを操作する場合、MVC のユーザーは人間ではなくブラウザーです。
後者の場合、バックエンドはフロントエンド アプリケーションの 1 つのデータ ソースのように機能します。MVC のフロントエンド部分全体が JavaScript で記述されています。
PS PHPコードを読める場合は、この回答でモデルレイヤーの非常に簡単な説明を見つけることができます。はい。MVC は、ゲスブックを作成するためではなく、大規模なアプリケーションで構造を強制するためのパターンであるため、「単純なバージョン」です。
http://www.asp.net/mvcサイトに移動し、チュートリアルやサンプルを参照して、Microsoft テクノロジを使用した MVC について学習できます。