15

私は最近、さまざまなタイプのモデルビューアーキテクチャについて少し調査を行っており、将来の社内開発のためにどれを追求するかを決定する必要があります。私は現在ASP.NETスキルを持つMicrosoftショップで働いているので、私の選択肢はASP.NET MVCとWCSFの間にあるようです（MonorailはMicrosoftでサポートされていないため、おそらく対象外です）。

WCSFを基準として使用して、ASP.NET MVCフレームワークを読んだ後、次の点を取り上げました。

  • ASP.NET MVCは、ポストバックに依存するWebコントロールを使用できませんが、WCSFは使用できます。
  • WCSFサイトではなく、ASP.NETMVCサイトのURLをより細かく制御できます。
  • ASP.NET MVCサイトは、同等のWCSFバージョンよりもテストが簡単になる可能性があります。
  • WCSFは、状況によってはUIイベントを制御するためにコードビハインドを使用しているようですが、ASP.NETMVCではこれが許可されていません。

他の考慮事項のいくつかは何ですか？
私は何を誤解しましたか？
両方のフレームワークを使用し、どちらかの方法でアドバイスを持っている人はいますか？

4

7 に答える 7

15

ASP.NET MVCは、ポストバックに依存するWebコントロールを使用できませんが、WCSFは使用できます。

WCSFは、既存のWebFormsインフラストラクチャの使用方法に関するガイダンスとして考える必要があります。特に、関心の分離を実施するためにModel-View-Presenterを導入する必要があります。また、結果のコードのテスト容易性も向上します。

WCSFサイトではなく、ASP.NETMVCサイトのURLをより細かく制御できます。

3.5 SP1をターゲットにできる場合は、従来のWebFormsサイトで新しいルーティングシステムを使用できます。ルーティングはMVCに限定されません。たとえば、動的データ（3.5 SP1でも出荷されます）を見てください。

ASP.NET MVCサイトは、同等のWCSFバージョンよりもテストが簡単になる可能性があります。

これは、HttpContext、HttpRequest、HttpResponseなどの新しい抽象化クラスを使用するためです。MVCパターンについて、MVPパターンほど本質的にテスト可能なものはありません。これらは両方とも「分離されたプレゼンテーション」のインスタンスであり、どちらもテスト容易性を向上させます。

WCSFは、状況によってはUIイベントを制御するためにコードビハインドを使用しているようですが、ASP.NETではこれを許可していません。

Model-View-Presenterでは、外界がビューと相互作用するため（つまり、URLがビューを指している）、ビューは当然これらのイベントに応答します。プレゼンターに電話するか、プレゼンターがサブスクライブできるイベントを提供することにより、可能な限りシンプルにする必要があります。

Model-View-Controllerは、外部の世界がコントローラーと相互作用することにより、この制限を克服します。これは、あなたの見解が非プレゼンテーションのことについて多くの「面倒」になる可能性があることを意味します。

どちらを使うべきかというと、プロジェクトの目標に最も適したものが答えになると思います。WebFormsと豊富なサードパーティコントロールベンダーの可用性が望ましい場合もあれば、生のシンプルさときめ細かいHTMLコントロールがMVCを支持する場合もあります。

于 2008-09-10T06:14:47.707 に答える
6

炎上戦争を開始するのではありませんが、WCSFは非常に複雑であることがわかりました。MVCの優雅さとシンプルさは、ウェブフォームに移植されたばかりのパターンのように感じるMVPを吹き飛ばします。

于 2009-12-17T18:02:47.170 に答える
2

まったく同じ評価を行った後、WCSFを選択しました。MVPパターンにより、サーバーコントロールを使用する機能など、より多くのオプションが提供されると感じました。私たちの開発チームは主にC++、Biztalk、Webなどの無数の分野のプログラマーで構成されていますが、すべてMSタイプの開発に重点を置いていたため、パターンを採用する際の学習曲線は私たちのチームにとってそれほど重要ではありませんでした。

私たちは私たちの選択に満足しています。

于 2009-02-04T10:01:39.350 に答える
1

ASP.NET MVCサイトは、同等のWCSFバージョンよりもテストが簡単になる可能性があります。

これは、HttpContext、HttpRequest、HttpResponseなどの新しい抽象化クラスを使用するためです。MVCパターンについて、MVPパターンほど本質的にテスト可能なものはありません。これらは両方とも「分離されたプレゼンテーション」のインスタンスであり、どちらもテスト容易性を向上させます。

これはおそらく議論の余地がありますが、ロジックが満載のビューがある場合は、MVCデザインモデルを使用する方がMVCデザインモデルよりも単体テストが簡単であることを示唆する文献があります。要約すると、MVPデザインモデルでは、プレゼンターはMVCデザインモデルのビューによって処理される可能性のある作業を処理しています。MVCビューに含まれている可能性のあるロジックは、単体テストを容易にしません。これは、この概念をカバーする私が読んだ文献への参照と、ユニットテストの促進を含む多くの理由でビューを明るく保つことが優れている理由です。

http://martinfowler.com/eaaDev/uiArchs.html

http://martinfowler.com/eaaDev/SupervisingPresenter.html

http://martinfowler.com/eaaDev/PassiveScreen.html

于 2012-01-25T17:45:50.897 に答える
1

MVCははるかに単純なパラダイムであり、他のすべてのフレームワークがWeb開発を行う方法に似ています。WebFormsは、単純さを実現するために、単純にあまりにも多くのフープと抽象化レイヤーを飛び越えています。IMHO、MVCは、数年以内にデフォルトのASP.NETアーキテクチャになります。これは、MVCがもたらす開発とテストのシンプルさと容易さを、ますます多くの人々が認識しているためです。私はMVC開発を1年半行っており、新しいプロジェクトでWebFormsに戻ることすら考えていません。

于 2009-12-17T18:13:02.580 に答える
1

また、開発者のバックグラウンドを考慮することもできます (すでに特定されている場合)。

彼らが厳格な asp.net のバックグラウンドを持っている場合、WCSF に慣れるでしょう (ただし、私の経験では、MVP に慣れるまでに数週間かかりました)。

彼らが Java/Rails のバックグラウンドを持っている場合、または以前に他の MVC アーキテクチャを使用したことがある場合は、明らかに満足するでしょう (そして、私の経験では、MVC 以外のことについて非常にスヌーピーになります)。

于 2008-10-09T02:56:08.670 に答える
0

両方を Northwind に接続して、どちらが自分の状況に最も適しているかを確認してみませんか?

于 2008-09-10T06:34:53.197 に答える