私の意見では、そうであり、そうではありません。
- ロジックとデータを UI から分離しますが、それでもすべてを 1 つのポイント アプリケーションに詰め込みます。
- コントローラはビジネス ロジックであり、ビューは UI であり、モデルは DAL であるため、実際にはそうではないと思います。これらは、同じアプリ内の単なるレイヤーになりました。
しかし、層は実際に層と呼ばれる最初または2番目の種類であると思われますか?
自分の 2 セントを追加したい人はいますか?
私の意見では、そうであり、そうではありません。
しかし、層は実際に層と呼ばれる最初または2番目の種類であると思われますか?
自分の 2 セントを追加したい人はいますか?
MVC テンプレート プロジェクトは、開始するためのものです。必要に応じて、コントローラーやモデルを別のプロジェクトに簡単に移動できます。また、アプリケーションでそれが理にかなっています。おそらく 3 つのコントローラー、Models レイヤー内のいくつかの余分なクラス、および EF または LINQ データ モデルを含む小さなアプリの場合、異なるプロジェクトに分離することを正当化するのに十分なファイルがないことを覚えておいてください。
私はコントローラーをビジネスロジックとは考えていません。それらは、アプリケーションロジック、ビジネスロジック(モデル)とプレゼンテーションロジック(ビュー)を結び付ける接着剤です。
さて、私のバースデーケーキは何層にも重なったけど、それでも1つの大きなケーキだった…そうですか?
レイヤーとティアは交換可能です。n層のコンテキストでは、それをプレゼンテーション層と呼びますが、階層化されたアプリケーションのコンテキストでは、それをプレゼンテーション層と呼びます。しかし、実際にはそれらは同じものです。
n層アプリケーションと緩い結合のリトマス試験は、各層を別々のプロジェクトとして構築し、それらを異なるマシンにデプロイできるかどうかです。
n層アプリケーションの主な差別化要因は、関心の分離(SoC)と低結合です。真に分離されたアプリケーションは、純粋なHTMLのみを含む層があるアプリケーションである可能性があります。次に、純粋なJavascriptを含み、AJAXを使用してDOMを更新し、Webサービスと通信する別の方法。Webサービスは、独自の層のセットで構成されています。
Webサービスには、要求をさまざまなコントローラーにルーティングするルーティングエンジンがあります。コントローラーは、要求をサニタイズして解釈し、認証などを検証して、適切なモデルを呼び出します。次に、モデルはPOCOオブジェクトまたはDTOを返し、それらをDOMに挿入するJavascriptに返す必要があります。Javascriptはオブジェクトを変更し、データベースに永続化するためにそれらを送り返す場合があります。Entity Framework 4.0は、SoC部門では少し不足していますが(たとえば、ビューを強く入力する)、そのようなn層シナリオを適切にサポートしていますが、より多くの目的で実用的です。
MVC Futuresは、箱から出してすぐに制御の反転(IoC)コンテナーをサポートしていると思います。現在、緩い結合と真のn層シナリオが必要な場合は、選択したIoCコンテナーを使用する必要があります。
「ティア」は通常、異なる物理サーバーを指し、「レイヤー」は疎結合領域への機能の分離を指します。
つまり、3 層の Web アプリケーション: 層 1) DB サーバー層 2) Web サーバー層 3) クライアント ブラウザ
3 層 Web アプリケーション: レイヤー 1) UI レイヤー 2) ビジネス ロジック レイヤー 3) データ アクセス