注：Webアプリケーションに適用されるMVCについて言及しています。MVCはさまざまな種類のアプリに適用でき、さまざまな方法で実装されているため、特定の実装ではなく、パターンによって定義されたものについて厳密に話しているのでない限り、MVCが特定のことを実行するかどうかを判断するのは非常に困難です。 。
あなたは「カプセル化」とは何かについて非常に具体的な見解を持っていると思います。その見解は、カプセル化の教科書の定義と一致せず、一般的な使用法とも一致しません。セッターがいないことを要求する「カプセル化」の定義はありません。実際、Setterはそれ自体がオブジェクトを「編集」するために使用されるメソッドであるため、一種のばかげた議論です。
ウィキペディアのエントリから（「ゲッターとセッターのように」と書かれているところに注意してください）：
一般に、カプセル化はOOP（オブジェクト指向プログラミング）の4つの基本の1つです。カプセル化とは、クラス内の変数などを非表示にして、許可されていない第三者が使用するのを防ぐことです。したがって、getterやsetterなどのパブリックメソッドはそれにアクセスし、他のクラスはこれらのメソッドを呼び出してアクセスします。
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming）
さて、それはMVCがカプセル化を破らないということではありません。私は、カプセル化が何であるかについてのあなたの考えは非常に具体的であり、特に標準的ではないと言っているだけです。
確かに、ゲッターとセッターを使用すると、オブジェクト自体の外部で直接変更できるリストを返すなど、多くの問題が発生する可能性があります。データを非表示に保つために（気にする場合は）注意する必要があります。コレクションを別のコレクションに置き換えることもできますが、これはおそらく意図したものではありません。
デメテルの法則は、ここでは何よりも関連性があります。
しかし、これはすべて、とにかく本当にただの赤いニシンです。MVCはGUIに関するものであり、GUIは可能な限りシンプルにする必要があります。ビューにもコントローラーにもロジックがほとんどないはずです。単純なビューモデルを使用して、フォームデータを単純な構造に逆シリアル化する必要があります。これを使用して、任意のビジネスアーキテクチャに適用できます（セッターが必要ない場合は、必要のないオブジェクトを使用してビジネスレイヤーを作成します）。セッターを使用し、ミュータッターを使用します。）
UIレイヤーに複雑なアーキテクチャーはほとんど必要ありません。UIレイヤーは、HTTPのフラットな形式とコマンドの性質を、選択したビジネスオブジェクトモデルに変換する境界およびゲートウェイのようなものです。そのため、HTTPはそうではないため、UIレベルで純粋にOOになることはありません。
これはインピーダンスミスマッチと呼ばれ、オブジェクトモデルはリレーショナルモデルに簡単にマッピングできないため、ORMに関連付けられることがよくあります。HTTPtoBusinessオブジェクトについても同じことが言えます。その点で、MVCはORMの当然の結果と考えることができます。