2012-02-17 4 views
1

私が働いているところでは、Webフォームプロジェクトとして.NET3.5で書かれたプロジェクトがあります。階層化されています。プレゼンテーション層、ロジック層、およびデータを後で表示します。階層化されたウェブフォームはMVCに分類されますか?

私たちは週刊の「技術セッション」を開催しています。私はMVCについてのプレゼンテーションをしました。

私の技術責任者は、上記のプロジェクト(階層化されたWebフォーム)はMVCと同じであると判断しました。彼は次のように記述するために行ってきました:

  • ビューだけでASPXページ
  • コントローラであるだけで、ページ尻です
  • モデルだけでデータが

かいつまんオブジェクトです - 私たちはに入ったが上記のプロジェクト(階層化されたWebフォーム)がMVCを構成するかどうかについての不安な議論。

誰かがこの討論に答えて答えることができますか?

ありがとう

+0

ウェブサイトのn層アーキテクチャに疲れているのは私だけですか? –

+0

言語とフレームワークを除いて、これはまだ 'モデル'、 'ビュー'、 'コントローラ'を持っているので、これは「MVCパターン」に従うと言えるでしょうか? – user1215399

答えて

2

いいえ。 mvcは主に懸念の強い分離に使用されます。コントローラーとビューは一緒に束縛されておらず、モデルが渡される(またはされない)以外に、他のものについての知識がありません。 1つのコントローラを使用して多くのビューをレンダリングすることができます。その場合、後ろのaspxコードはすべて同じ部分クラスの一部であるため、単一のaspxページに強く結びついています。ほとんどのmv​​cアプリケーションでモデルが実際のドメインのデータ型ではなく、ビューをレンダリングするために使用できるいくつかの複合体であると言う以外に、モデルはそれほど違いはありません。

もう1つはmvcと異なり、階層的な階層構造と命名規則です。ベストプラクティスを促進し、やはり懸念の分離を促します。

microsoftが理由でasp.net mvcフレームワークを作成しました。ルーティングなどを使用してWebフォームでmvcの感じをエミュレートすることはできますが、これはまったく同じことではありません。

また、これはasp.net mvcに向かって傾斜していますが、明らかにそこに他の多くのフラクタルがあります。私はあなたもFubuMVCをチェックアウトすることをお勧めします。

+0

コントローラーが単なるデータマネージャーであると主張したらどうでしょうか?例: - ビューはASPXページ - コントローラーはデータアクセスクラス - モデルはデータオブジェクト – user1215399

+0

@ user1215399ですが、これは依然として誤った評価になります。コントローラはルータのようなものです。要求を受け取り、適切なビューにルーティングします。私は実際にコントローラは実際にかなりのデータにとらわれず、ビューに渡すモデルについてのみ知っていると主張しています。 –

+0

言語とフレームワークを除いて、これはまだ 'モデル'、 'ビュー'、 'コントローラ'を持っているので、これは「MVCパターン」に従うと言えるでしょうか? – user1215399

1

a pattern MVCは、特定のテクノロジ(WebForms、WinForms、ASP.NET MVCなど)には依存しません。

WebFormsで実際にMVCを実行することは非常に可能です。

CodeBehindファイルはコントローラとして扱うことができますが、技術的には間違っています。コードビハインドファイルとaspxファイルの両方が部分クラスであるため、ちょうどONEタイプにコンパイルされるため、コントローラタイプとビュータイプはありません問題); しかし、この違いはマイナーなものとみなされるかもしれません。

WebFormsはMVCパターンを実装するものとして見ることができ、非常に簡単に邪魔になる可能性がある非常に醜い実装であることを認めています。しかし、一度それが(通常は起こるように)台無しになると、ViewとControllerの間の分離の懸案事項は少なくとも侵害されるので、この分離がぼやけたり消えたりすると、もうMVCではないと言わなければなりません。

レジュメ:WebFormsはMVCパターンの実装として扱うことができますが、この実装でこのパターンに従うのは本当に難しいので、MVCのままであり、そのコンセプトにとどまることはほとんどありません。

+0

コントローラーが単なるデータマネージャーであると主張したらどうでしょうか?例: - ビューはASPXページです - コントローラはデータアクセスクラスです - モデルはデータオブジェクトです – user1215399

+0

Webフォームでmvcを正常に実装した人は誰も見たことがありません。試してみるのは愚かなようだ。 mvpはWeb/Winフォームで入手できるほど良くなっています –

+0

@ user1215399いいえ、私は決して言いませんでした。私の場合、コントローラはデータアクセスクラスではなく(リポジトリも可能です)、モデルはDTOの束ではありません。 –

1

技術的なリードは間違いです。

真のMVCフレームワークを使用したことのない人々の間では、「MVC」はウェブフォームとはまったく違った風潮です。

このような理由を理解するには、MVCのアーキテクチャパターンと、MVCパターンを実装するMicrosoftによって構築されたフレームワークのASP.NET MVCの違いを理解する必要があります。

多くの場合、かなりの話題を理解していない、このようなハイテクリードや建築家などの人々は、2本の違いを理解せずパターン枠組みの両方を記述するために「MVC」の用語を使用します。しばしば混乱を招く。

ので、明確にするために、MVCパターンは新しいものではない、そしてそれは実際にのようなフレームワークの多くによって実装されています。

Webformsはではありません。 MVCパターンを実装したフレームワークの1つです。

WebFormsにMVCパターンを実装することは可能ですが、WebformsはMVPスタイルパターンを実装する方が適しており、この点については実際にフレームワーク(such as this one)があります。

ハイテクリードは、彼が話しているものは考えていないことが最大の指標は、しかし、これは次のようになります。

マイテックリードで切断し、 (階層、Webフォーム)上記のプロジェクトということを教えすることにしましたMVCと同じです

「アプリケーション」に「ティア」を導入することは、MVCとは関係ありません。実際、階層構造のアーキテクチャでは、MVCアプリケーションはプレゼンテーション層内に完全に配置され、他のアプリケーション層とは何の関係もありません。

フロントエンドにASP.NET MVCを使用すると、ASP.NET MVCフレームワークを使用して実装されたロジックレイヤーの上にプレゼンテーション層が存在することを意味します。単にMVCを使用しているため、他の層の必要性を突然なくしたというわけではありません。

逆に、Webフォームは、階層構造内のプレゼンテーション層に過ぎません。階層化されたアーキテクチャを使用しているのは、MVCパターンを使用していることを意味するものではありません。他の点のそれぞれに

ビューは、これは真実ではないだけでASPXページ です。 ASPXページは非常に複雑な獣であり、MVCのビュー間の1つの非常に大きな違いがあります。

彼らは、彼らがするように設計されて、このページ全体のライフサイクルとビューステートのシステムとコントロールを持っている状態

を維持するために設計されていますポストバックの間の状態を維持する。

ASP.NET MVCはステートレスであるように設計されているため、ビューにはこうした複雑さが含まれていません。

コントローラは、単にページ-尻

この文は完全にコントローラのポイントを見逃しています。

コードビハインドは、ASPXページをレンダリングするプロセスに関係するすべてのことを明示的に認識しています。ページ上のコントロール、ページの状態、ページのライフサイクルを把握しており、非常にが密接に結合されています。が表示されます。

コードビハインドも1つしか戻っていません。 aspxページ。

コントローラは、はるかに柔軟であり、唯一のビューを返すことはできませんが、彼らはあなたのデータの異なる表現をレンダリングするための制御ロジックに使用することができます。たとえば、標準のhttpリクエストではHTMLと同じデータをレンダリングしたり、AJAXリクエストではJSONとしてレンダリングしたりすることができます。

コントローラロジックとビューロジックは疎結合があるので、これは可能であるこれを可能にするものである

モデルは単なるデータが

これは間違っているオブジェクトです。どのような種類の複雑なMVCアプリケーションでも、データオブジェクトをビューに直接バインドすることはまれです。簡単に言えば、データをデータベースでモデル化する方法は、ビューを表示するために必要なデータを表すことはめったにありません。

たとえば、「TitleId」という従業員レコードがあるとします。レコード内のデータはint型にすぎませんが、実際のテキスト値をユーザーに表示して意味をなす必要があります。

ほとんどのMVCアプリケーションでは、「モデル」は実際には「ViewModel」としてより正確に記述され、データモデルやドメインモデルとは完全に分離されています。

あなたのハイテクリードで「あなた-持っ-NO-アイデア - 何-you're-トーキングについて」ちょうどセマンティックレベルで間違っている、間違った間違っている、とされていない要約する

レベル。

  • Webフォームを使用した階層アーキテクチャを使用しても、MVCパターンが実装されているわけではありません。
  • ASPXページには、何も
  • ビューのようなCodebehindsは
  • コントローラのようなモデルがデータオブジェクトとは何の関係もない、何もされていません。

希望するものがあります。

+0

言語とフレームワークを除いて、これはまだ 'モデル'、 'ビュー'、 'コントローラ'を持っているので、これは「MVCパターン」に従うと言えるでしょうか? – user1215399

+0

ロースト・ラムを食べて、メインの食事の後にそれを提供したとしたら、それは砂漠になるでしょうか?アイスクリーム、カスタード、砂漠のワインを添えて、それを砂漠にしますか?いいえ、それは一般に受け入れられている砂漠の定義に従わないためです。 Webformsでも同じです。プロジェクトに「モデル、ビュー、コントローラ」と呼ばれるクラスをいくつか振りかけるだけで、アイスクリームでローストラムを提供することは、それを砂漠にしてしまうだけで、MVCの実装にはなりません。 – lomaxx

関連する問題