応用情報技術者 2011年 春期 午前2 問15
問題文
モデル、ビュー層及びコントローラ層の三つの論理的な層でモデル化された Webシステムの説明として、適切なものはどれか。
選択肢
ア:業務処理はコントローラ層が行い、出力が必要な場合はビュー層に依頼する。
イ:業務処理はモデル層が行い、処理結果はビュー層に渡されて画面表示が行われる。(正解)
ウ:処理に必要なデータをモデル層が検索し、コントローラ層で業務処理が行われる。
エ:モデル層はコントローラ層から受け取った処理結果をビュー層に引き渡す。
🔒 解説は解答すると表示されます
MVCの各層の役割【午前2解説】
正解の理由
設問の中で最も適切なのは選択肢イです。理由は次の通りです。モデル層は業務ロジックとデータ操作(ビジネスルール、永続化のためのデータ取得・更新など)を担い、ビュー層は画面表示・表現のみを担当します。処理の流れとしては、コントローラ層がユーザ要求を受けてモデルに業務処理を依頼し、モデルの処理結果を受け取ったコントローラが適切なビューにそのデータを渡して画面表示を行います。選択肢イは「業務処理はモデル層が行い、処理結果はビュー層に渡されて画面表示が行われる」と述べており、モデルが業務処理を担い、最終的に結果がビューで表示されるという要旨が正しいため適切です(ただし結果の受け渡しは通常コントローラが仲介します)。
解法ステップ
- 各層の責務を明確にする
- モデル:業務ロジック、データ操作(永続化含む)
- コントローラ:要求受付、モデル呼び出し、ビュー選択とデータ受け渡し(仲介)
- ビュー:表示(プレゼンテーション)だけを担当
- 選択肢を上の責務と照合する
- 「業務処理を行うのはどの層か」を軸に誤りを排除する
- 「どの層が他の層へデータを直接渡すか」を確認し、仲介者が必要かを判定する
- 文の意味を厳密に解釈する(直接渡すのか、最終的に渡されるのか)
- 選択肢の文言が「最終的にビューで表示される」を指しているなら正しいが、「モデルが直接ビューに引き渡す」と明示している場合は誤りと判断する
選択肢別の誤答解説
-
ア: 「業務処理はコントローラ層が行い、出力が必要な場合はビュー層に依頼する。」
誤り。コントローラは振る舞いの調整(ルーティングやモデル呼び出し、ビューへの仲介)を担うが、業務ロジックそのものはモデル層が担当する。コントローラに業務ロジックを実装すると責務の分離が損なわれテストや再利用性が低下する。 -
イ: 「業務処理はモデル層が行い、処理結果はビュー層に渡されて画面表示が行われる。」
正解。モデルが業務処理を担当し、処理結果は最終的にビューで表示されるという点が正しい。ただし重要な点として、処理結果の受け渡し自体は通常コントローラが仲介する(モデルが直接ビューへ渡すことは責務の混同となる)。選択肢は「結果がビューで表示される」という最終状態を述べており、設問としては適切と評価される。 -
ウ: 「処理に必要なデータをモデル層が検索し、コントローラ層で業務処理が行われる。」
誤り。ここは責務の逆転が生じている。モデルがデータ取得を行う点は正しいが、業務処理をコントローラで行うのは不適切。業務ロジックはモデルに置くべきで、コントローラはその呼び出しや結果の仲介にとどめる。 -
エ: 「モデル層はコントローラ層から受け取った処理結果をビュー層に引き渡す。」
誤り。モデルは通常、自身で処理を行って結果を返す役割であり、結果をビューへ直接引き渡す責務を持たない。ビューへの受け渡しはコントローラが仲介して行うのがMVCの責務分離に合致する。
よくある誤解
- モデルがビューに直接データを渡すと思い込む
- 「処理結果がビューに表示される」という表現を誤解し、モデル→ビューの直接渡しを想像しがちです。実務・試験における標準的な理解は「結果は最終的にビューで表示されるが、その受け渡しはコントローラが仲介する」です。
- コントローラを「単なるルーティング」と過小評価する
- コントローラは単純な入口だけでなく、ユーザ入力の検証、モデルの呼び出し、どのビューを使うかの決定など重要な調停役を担います。
- モデル=単なるデータベースアクセスと考える
- モデルはデータアクセスだけでなくビジネスルールやトランザクション管理など業務ロジック全体を含みます。
補足コラム
MVCの実装はフレームワークや用途によって微妙に違います。たとえばDjangoでは「MVT(Model-View-Template)」と呼ばれる派生があり、テンプレートがビュー表現を担いますが役割分離の考え方は類似しています。近年はフロントエンド側でのMV*系(例:MVVM)も普及しており、責務分離の原則は変わらないものの、どの層がどの処理を担当するかは設計に応じて明確に定義することが重要です。
例:典型的なWebアプリの処理フロー(擬似コード)
# controller.py
def show_order(request, order_id):
# 1. 入力検証など(コントローラ責務)
# 2. モデルに業務処理を依頼(モデルが業務ロジックを実行)
order = OrderModel.get_order_with_totals(order_id)
# 3. ビュー(テンプレート)選択とデータ渡し(コントローラが仲介)
return render_template("order_detail.html", order=order)
FAQ
Q1: モデルはデータベースのテーブル定義そのものですか?
A1: いいえ。モデルはデータ構造(エンティティ)だけでなく、ビジネスルールや永続化のための操作、検証、トランザクション管理など業務ロジック全体を含みます。
A1: いいえ。モデルはデータ構造(エンティティ)だけでなく、ビジネスルールや永続化のための操作、検証、トランザクション管理など業務ロジック全体を含みます。
Q2: 小規模アプリではコントローラに業務ロジックを置いてもよいですか?
A2: 小規模でも将来の拡張やテスト性を考えると、業務ロジックは可能な限りモデルに置くことを推奨します。そうすることで責務が分離され再利用性と保守性が向上します。
A2: 小規模でも将来の拡張やテスト性を考えると、業務ロジックは可能な限りモデルに置くことを推奨します。そうすることで責務が分離され再利用性と保守性が向上します。
Q3: フロントエンドMVC(例:Reactでの構成)でも同じ役割分担ですか?
A3: 原則は同じ(責務分離)ですが、フロントエンドでは状態管理やビュー更新の考え方が異なり、MVVMやFlux/Reduxのような別のパターンが使われることが多いです。設計原則を理解して適切なパターンを選んでください。
A3: 原則は同じ(責務分離)ですが、フロントエンドでは状態管理やビュー更新の考え方が異なり、MVVMやFlux/Reduxのような別のパターンが使われることが多いです。設計原則を理解して適切なパターンを選んでください。
関連キーワード: MVC、モデル層、コントローラ層、ビュー層、責務分離、ビジネスロジック、プレゼンテーション層、アーキテクチャ設計

\ せっかくなら /
応用情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

