asp.net-mvc - .Net 3.5 で MVC フレームワークを使用して従来の ASP に移行していますか?

Question

MVC フレームワークを見ると、ASP.NET ポストバックやビューステートよりも従来の ASP の知識が必要なようです。実際のフロントエンド HTML マークアップで、複雑な UI + コード ロジックに逆行しているのでしょうか?

Answer 1

HTML や HTTP リクエストなどの基本的な概念を抽象化しようとしない方向に戻ります。UI 側では、これはビューが出力とより緊密に統合されることを意味しますが、これは悪いことではありません。従来の ASP モデルは、すべてが出力と緊密に統合されるようになりましたが、これは悪いことです。

Answer 2

ASP.NET パラダイムが一歩前進したと考えると、MVC パラダイムは一歩後退したと主張する人もいるかもしれません。個人的には、標準の HTML エディターではアクセスできないコード ブロックに表示出力テキストがマッシュアップされる .NET よりも、従来の ASP できれいに分離されたコードを記述する方がはるかに簡単だといつも思っていました。ASP.NET アーキテクチャは、アプリケーションの全体的な構造を改善するというよりは、.NET を推進するためのものだと常に思っていました。その意味で、MVC は一歩前進です。

Answer 3

あなたがこれについて言及するのはおかしいです... 私は今日、同僚と同じ会話をしていました。

一歩後退ですか？私はそうは思いません...古典的なASPでは、UIに複雑なロジックがありましたが、MVCで見ることができることから、複雑なロジックはビジネスオブジェクトにある必要があり、オブジェクトとの複雑な相互作用は必要ですコントローラを介して行われます。

繰り返しますが、私が見る限り、目標は、実際のビジネス ロジックに関しては、UI をトリム アンド フィットすることです。AJAX や JQuery などを使用して UI をよりユーザー フレンドリーにすることで、さらに肥大化する可能性があります。

これは、MVC に関する私の最初の観察です。これは非常に優れたテクノロジであり、特に REST の上にあるため、他のテクノロジとの連携が非常に簡単になります。

将来のいくつかのプロジェクトでそれを試すことを楽しみにしています!

Answer 4

モデルとコントローラーに関連するビューに複雑なコード ロジックが表示されている場合は、おそらく間違った方法でアプローチしている可能性があります。

純粋な意味では、最小限の作業でビュー (たとえば、HTML ではなく XML) を切り替えることができるはずです。これは、データ ロジックがモデルに含まれ、ビジネス ロジックがコントローラーに含まれている場合にのみ発生する可能性があります。

そのため、ショッピング カートを表示している場合、ビューには製品の数量と合計を書き出すコードしか含まれていない可能性があります。モデルクラスは製品データを保持し、コントローラーは製品の追加やチェックアウトなどのすべての処理を行います。

Answer 5

MVC の全体的なポイントは、コードの分離です。モデルにはすべてのビジネス ロジックが含まれている必要があり、ビューはユーザーへの出力を処理するだけであり、コントローラーはこれら 2 つの部分を結合する必要があります。