最近、MVC パターンがアプリケーションのレイヤーを説明しているというテキストを読みました。しかし、個人的には、MVC がアプリケーションでいくつかの重要な役割を示していると思います。
MVC の 3 つの主要部分を説明するのに、レイヤーとロールのどちらの言葉が適していると思いますか?
最近、MVC パターンがアプリケーションのレイヤーを説明しているというテキストを読みました。しかし、個人的には、MVC がアプリケーションでいくつかの重要な役割を示していると思います。
MVC の 3 つの主要部分を説明するのに、レイヤーとロールのどちらの言葉が適していると思いますか?
レイヤーは、それぞれのコード セット間の結合が非常に狭いことを意味する必要があります。MVC には、モデル、ビュー、およびコントローラー間の比較的緊密な結合が含まれます。したがって、これをレイヤリング パターンとして特徴付けると、レイヤ間の API を定義するという点で問題になります。これを適切に行うには、いくつかの非直感的なパターンを実装する必要があります。
このため、単一のレイヤー内で役割を定義するパターンとしてそれを表示する傾向に同意します。
役割はより良い説明だと思います。ビューとコントローラーは両方とも同じ「レイヤー」にあり、通常、モデルはレイヤーとして記述されますが、レイヤー間で使用されます。
通常、私のアプリケーションは、プレゼンテーション、永続性、ファイル io などを含むドメイン モデルを中心にしています。アーキテクチャを階層化されたものとして考えることは、私にとってはうまくいきません。
MVC では ROLES が明確に定義されています。これらは、任意の数のレイヤーに実装できる 3 つの役割です。たとえば、マルチレイヤーコントローラーを使用できます
層ではなく役割。レイヤーは、MVC パターンの基礎となる実装に完全に依存しています。たとえば、サービス レイヤーは、ある実装では単一のレイヤーである場合がありますが、別の実装では Web サービス リモーティング レイヤーとデータベース レイヤー (2 つの異なるサービス レイヤー用) を持つことができます。レイヤーの概念は、パターンと同様に整理するのに役立ちますが、レイヤーはパターンほど簡単に見つけることができず、レイヤーが変更される可能性がありますが、実装が異なるためにレイヤーが変更されてもパターンは同じままです。
この 2 つの単語は異なる概念を表しているため、比較することはできません。私にとって、レイヤーとは何かを行うために使用できるいくつかの機能を提供する不透明なものです。たとえば、ワイヤレス送信機用の優れたハードウェア レイヤーは、送受信機能 (たとえば、バイトに基づく) を提供するだけで、醜い、醜い詳細をすべて隠します。
ロールとは、オブジェクトの動作方法です。たとえば、私のコンパイラの 1 つでの変換は、抽象構文木を取り、抽象構文木を返します。または、現在のプロジェクトの愛情は、状態差を取り、特別に変更された状態差を返します。
しかし、これらの 2 つの定義について考えると、1 つの「正しい」用語を選択して、他の用語を間違っていると非難する必要はないと思います。レイヤーの一部には特定の役割があり、特定の役割に適合するオブジェクトの集合がレイヤーを形成します。確かに、コントローラーは UI とモデル (少なくとも入力用) の間に特定のレイヤーを形成しますが、役割もあります。特定のイベントを特定の他のイベントに変換します (したがって、ある種のアダプターです)。
どちらも合理的に議論できると思いますが、パーツを「レイヤー」として説明する方が、OSI モデルなどの他の規則とより一貫していると思います。View、Controller、および Model は徐々にデータに近づくため、より階層化された構造になります。「役割」は、同じレイヤー上のアプリケーションのさまざまな部分に適用されるようです。
それはすべて用語ですが、正しいソフトウェアアーキテクチャ用語は、論理層のように「層」になると思います。より明確な場合は、「アーキテクチャ層」という用語を使用できます。
問題は、アプリケーションをスライスする別の方法にすぎないということです。従来の n 層アプリは次のようになります。
単純な MVC アプリケーションには、次の論理レイヤーを含めることができます。
しかし、「UI」と「コントローラー」をまとめてユーザー インターフェイス レイヤーを構成することもできますが、私は通常、これらのアーキテクチャーを説明および図化するときに、コントローラーを別のレイヤーに分割します。
なぜ両方ではない?私はそれを、3 つの異なる役割を実装する 3 つの別個のレイヤーと見なしています。