5

私は最近いくつかの議論に参加しており、その話は、現在 ASP.NET Web フォームである製品の将来の作業のために ASP.NET MVC と Knockout に移行することについてです。この製品は、SPA の一般的な現在の定義の多くの特性を備えています。

JSON Web サービスへの呼び出しからデータを取得する JS ビュー モデルを使用してすべてのビューを生成し始めるときに、MVC が実際にどのように適合するかを私は見たことがありません。

Knockout w/JS モデルと JSON および MVC フレームワークの最良の部分を活用する「スイート スポット」はありますか?

これについて私が考えていることがいくつかあります（少しランダムです-いくつかの議論/回答に拍車をかけることができるかどうかを確認しています）：

  • Knockout と Razor のどちらを使用しますか? Knockout は、実行時にクライアント ブラウザでビュー要素を生成します。Razor は、クライアントが応答を受信する前に、サーバー要求の一部として実行されます。どちらかが明らかに優れている場合や、個人の好みによる場合はありますか?
  • コード補完の目的で、C#/Razor を装ってより多くのコードを保持する価値はありますか? また、例外がスローされた場合、コンパイルされたコードへのスタック トレースは、JS デバッグよりも簡単に見えます。
  • 空の ASP.NET アプリケーションと独立した Web API プロジェクトを作成して、ビューをバックエンドから完全に分離した方がよいでしょうか?
4

1 に答える 1

5

素晴らしい質問がたくさんあります。このテーマに関する私の考えをいくつか共有します。（質問は言い換えられています）：

1)ノックアウトの世界に MVC の場所はありますか? - 絶対。MVC は単なる Razor ではありません。サーバー側のルーティング、エリア、認証などはすべて MVC によって提供されます。したがって、私の考えでは、すべての「管理者と組織」に MVC を引き続き使用できますが、すべてのビューを主に (必ずしも完全にではなく) AJAX 駆動にすることができます。以前、SO でMVC と KO を一緒に使用することについて説明しました。また、WintellectNOW ドットコムでそのトピック専用のビデオを持っています。

2) Razor はいつ使用する必要がありますか? - 実際に用語を入れ替えてみましょう。これは Razor と Knockout の違いではなく、サーバー側とクライアント側のレンダリングの問題です。では、いつサーバー側レンダリングを使用する必要があるのでしょうか? この最適なタイミングの 1 つは、ページの初期化時に 1 回だけ実行する必要があるデータをロードする場合です。たとえば、ドロップダウン用の状態のリストがあり、そのリストが変更される可能性が非常に低い場合は、先に進んでそれをサーバー側にロードします。その場合、なぜ向きを変えて別のリクエストを API に戻すのでしょうか? これらの呼び出しは、動的データまたは状況依存データ用に予約します。

3)ツールの目的で C# に多くのコードを保持する価値はありますか? -私見、いいえ。確かに JS のデバッグは骨の折れる作業ですが、だからと言って、クライアント側でできるすばらしいことをすべて無視することを正当化するのには十分ではありません。より良いユーザー エクスペリエンスを提供するために、ときどきフラストレーションを感じるだけの価値はあります。

4)コードを分離しておくために、Web API を別のプロジェクトに移動する必要がありますか。- プロジェクトのニーズに完全に依存します。Web API プロジェクトが複数のアプリケーションにサービスを提供する場合は、はい、別のプロジェクトにする必要があります。また、別の DOMAIN、SUB、PORT などに配置して、Web アプリの残りの部分と区別します。これを行うと、クロス オリジン リソース共有 (CORS) の問題が発生します。CORS は、絶対に必要な場合を除き、私が経験したくない特定の地獄です。Web API が単一の Web アプリにのみサービスを提供する場合は、同じプロジェクト内に保持してください。

他のすべてと同様に、これの多くは個人的な好みに帰着します. 私は、サーバー側を使用してアプリの全体像を管理し、クライアント側をすべての UI/UX に使用することです。

于 2013-10-27T13:18:00.947 に答える