別のユーザーは、いくつかのAJAX投稿の問題を処理するためにKnockoutMVCを提案しました。少し読んでみると、KnockoutJSのラッパーであることがわかります。では、この2つの本当の違いは何だろうか。Knockout MVCが存在するので、 Knockout JSを気にする必要がありますか？いつ使用しますか？
18420 次
12 に答える
125
Knockout MVCは、WebFormsのろくでなしの子です。すべてのviewmodelメソッドをコントローラーアクションを介してルーティングします。つまり、発生するすべてのものがサーバーにバウンスして戻る必要があります。CLIENT SIDE MVVMを対象としたノックアウトのようなフレームワークを採用し、すべての機能に対してサーバーを呼び出すように強制する理由がわかりません。
さらに、サーバーでこれらのメソッドを実行すると、関数呼び出しごとに、ビューモデル全体をサーバーに渡し、クライアントに戻す必要があります。これは非常に無駄です。
Knockout MVCを使用するということは、JavaScriptを記述しなくても済むように、クライアント側のコードのパフォーマンス上の利点をすべて犠牲にすることを意味します。同じトレードオフのWebフォームが作成されました。それは良いものではありません。アンチパターンです。
Knockout MVCが明日死んだ場合、Webはより良い場所になります。
于 2012-07-23T18:20:39.517 に答える
21
かなり否定的な反応があるこの質問に出くわしました。私はすぐに私の2セントの価値を追加するつもりです。
KnockoutJSを使い始めたばかりです。ASP.NET MVCアプリを構築しているので、KnockoutMVCのようなものを使用するのは理にかなっているように思えました。ほとんどの場合、それは素晴らしいアイデアのようです。<!-- ko -->私が知っていて大好きな.Net機能を使用して同じことができるのであれば、自分のページでJavaScriptやコメントを書くことに時間を費やしたくありません。
そうは言っても...はい、現時点ではKMVCには制限があります。モデル全体をサーバーに送り返すことは大きな問題です。だから私がやったことは、ノックアウト-mvcの私自身のフォークを始めたことです。現時点では、変更は必然的に急いでいます。しかし、私は今、次のことができるようになりました。
- サブコンテキストを作成します（ビューモデルの完全に異なるモデルまたはコンポーネントを使用）
- サーバーを呼び出すときに、モデルの選択した部分を戻します
- 送信されたものとは異なるモデルがコールから返されることを期待します
- ajax呼び出しの周りの火災イベント
- より多くのhtml5入力タイプをサポート
- 偽造防止トークンをヘッダー経由でサーバーに渡します（ajax呼び出しの場合）
- おそらくもっと忘れてしまった
私はすぐに戻って、私がしたことを本当にきれいにすることを望んでいます。うまくいけば、作者はこれらの変更を自分のコードに含めるでしょう。そうでなければ、私は自分のフォークを続けていくと思います。いずれにせよ、トンネルの終わりには光があります。KMVCは現状のままで作業が必要かもしれませんが、このコンセプトは間違いなくやりがいがあると思います。
私は間違いなく思います
Knockout MVCが明日死んだ場合、Webはより良い場所になります。
少し厳しいものでした。
編集：
コメントを見て、元の質問が何であるかをもう一度見ました。それを行った後、私はもう少し私の答えに追加する必要があると思います：
最初の質問は、KnockoutJSの代わりにKnockoutMVCを使用する理由はありますか？Knockout MVCは、KnockoutJSをASP.NETMVCアプリと簡単に統合できるように設計されたフレームワークです。これは主に、よく知られている強い型の構造を使用してKnockoutJSタグを生成することによって行われます。KnockoutJSに代わるものではありません。ぜひKnockoutJSをご利用ください。問題は、KnockoutMVCも使用するかどうかです。
そうは言っても、利用可能なすべてのツールのさまざまな側面をいつ使用するかを選択するのは、開発者としての選択です。サーバーに対して完全なリクエストを実行して機能の特定の側面を処理する場合は、それを実行します。データを取得/更新するためにajaxリクエストを実行する場合は、それを実行します。純粋にクライアント側で機能を実行したい場合は、それを実行します。
Knockout MVCを使用しても、KnockoutJSを最大限に活用できます。Knockout MVCを使用しても、クライアント側の機能を必要なだけ処理するための追加のJavaScriptを作成できます。Knockout MVCがサーバーへのajaxコールバックを生成するためのショートカットを提供するからといって、それらを使用する必要があるわけではありません。ただし、アプリケーションがデータを永続化する場合は、ある時点でホームに電話する必要があります。
静的HTMLおよびスクリプトファイルを提供するためにApacheを使用するのと比較して、ASP.NETMVCを使用してアプリケーションバックエンドを構築する理由があります。Knockout MVCを使用すると、これらの同じ利点を引き続き利用して、KnockoutJSの統合を支援できます。
于 2013-09-17T02:44:13.210 に答える
13
Tyrsiusの答えは少し否定的すぎると思います。Knockout MVCはまだ開発の初期段階にありますが、私が見る限り、いくつかの利点があり、たとえばWebformsよりもサーバーの負荷が少ないことがわかります。可視性の依存関係は、関数を使用してサーバーに対して呼び出しが行われる場合にのみ、クライアント上で完全にハンドルを取得します。複雑なデータ構造を操作する場合、とにかくサーバーを経由する必要がある場合があるため、Knockout MVCは、多くのAjax処理を自分で作成する手間を省くための良い方法かもしれません。
確かに、モデル全体を常に前後に送信するため、自分でモデルを作成するのではなく、ある程度のオーバーヘッドが発生します。しかし、私はそれを完全に帳消しにするつもりはありません。特に、将来的に複雑な検証のために適切なクライアント側の処理を取得する場合。
于 2012-07-27T09:01:09.257 に答える
11
ノックアウトMVCについて少し検索した後、この投稿に出くわしました。私はネットワーク帯域幅の浪費に同意しますが、私はそのコード行にかなり魅了されています：
@{
var ko = Html.CreateKnockoutContext();
}
これは、ノックアウトビューモデルを生成するためのすっきりとしたクリーンな方法です。すべてのロジックをサーバー側に移動せずに、その機能のためだけにノックアウトMVCを使用した人はいますか？
于 2013-03-11T15:33:34.513 に答える
8
Knockout.jsの優れている点は、サーバーがHTMLを生成するためにチャンクする必要のあるビュー全体をプッシュすることなく、サーバーとの間でJSONをやり取りするだけでアプリケーションを提供できることです。
それをサーバーに戻すのは非常に直感に反しているようです。興味がある場合は、そもそもかみそりの構文を使用してバインディングを実行することをお勧めします。
私の提案は、knockout.jsを使用してバインディングを実行し、これが目的の目標である場合は、サーバーではなくクライアントでバインディングが行われるようにすることです。ビューをサーバー上でデータバインドする場合は、かみそりを使用します。
于 2012-07-23T18:21:52.023 に答える
6
さらに、knockout.jsは、クライアント側のデータの表示/削除/挿入/更新、およびクライアント側のデータ計算に非常に優れています。実際のビジネスロジックがそれと同じくらい単純な場合は、knockout.jsを直接適用する必要があります。
真実は、ビジネスロジックは必ずしもそのように単純ではないということです。たとえば、クライアントがビューに新しいレコードを挿入する場合、システムはユーザーの認証を確認し、ビジネスロジックや式などに基づいて新しく作成されたオブジェクトのデフォルト値を設定する必要がある可能性があります...これはすべて、とにかくサーバー側に移動して確認する必要がありますデータベースデータに基づくロジック。
開発者は、必要なすべてのビジネスロジックをknockout.jsビューモデル内のJavaスクリプトメソッドに変換できます。しかし、このように、設計はビジネスロジックを一元的に処理するという規則に違反します。
維持はそのような設計にとって悪夢になるでしょう。
要約すると、どのフレームワークの選択が実際にビジネス要件に依存するか。場合によっては、パフォーマンスが最初の考慮事項ではありません。
于 2013-11-17T22:04:03.647 に答える
6
KnockoutMVCライブラリの優れたユースケースもたくさん見られます。たとえば@ChinaHelloWorldによって指摘された理由のために、KnockoutJSをMVCWebアプリに統合することはほとんどできませんでした。これが私が非常に役立つと思ういくつかのケースです。
- 強い型のバインディング
KnockoutJSのセットアップに関しては、完全に役に立たず、面倒になってしまった、強く型付けされたHTMLヘルパーメソッドが気に入りました。私ができる最善のことは、ヘルパーメソッドの追加パラメーターを使用してバインディング属性を手動でアタッチすることですが、そこで再びマジックストリングを使用する必要がありました。強く型付けされたC＃式ベースのバインディングを使用して入力やその他の要素を作成するためにKnockoutMVCが提供するヘルパーが好きです。ただし、ここで、生成されたフィールドのname属性が欠落しているため、少し調整する必要がありました。
- 強く型付けされたバインディング構文（種類）
純粋な文字列バインディングを使用する場合、つづりを間違えたり、適用したいバインディングの正しい形式が正確にわからない可能性が常にあります。KnockoutMVCとVSIntelliSenseの流暢なAPIを使用すると、正しいバインディングを簡単に適用できます。
- （ほぼ）計算されたC＃プロパティから計算されたバインディングへの自動変換
小さな[Computed]属性を適用するだけで、KnockoutMVCは対応するバインディング式を正しいKnockoutJS構文で生成できます。これもとても便利だと思います。
- ビューモデルコードの重複はありません
古典的な方法では、C＃コードでviewmodelクラスを作成し、次に（ほぼ）JSで同じviewmodelコード（オブザーバブルを使用）を作成する必要がありました。そうですね、それは私にとって苛立たしいことでした。KnockoutMVCで使用されている手法を見て、私は非常に満足しました。ただし、非常に複雑なビューモデル（ネストされたビューモデル、コレクションなど）で使用できるようにするため、およびマップされたノックアウトビューモデルを必要なカスタムJSメソッドや計算されたオブザーバブルなどで拡張できるようにするために、少し調整する必要がありました。 。
したがって、ここに少なくとも4つの非常に良い点があります。そして、ビューモデルのラウンドトリップについて：誰も私たちの誰もがノックアウトMVCのサーバー側の処理メカニズムを使用する必要があるとは言いませんでした。サーバー上で実際に処理する必要のある複雑なビジネスロジックがある場合にのみ、これも使用しません。ただし、ほとんどの場合、Knockout MVCは、MVCビューとKnockoutJSのバインドとセットアッププロセスを簡素化するためのものです。ですから、上記の悪い意見はよくわかりません。これらの意見を書いた人は、少なくともKnockoutMVCの基本的な概念を学ぶ努力をしなかったと思います。Youtは、KnockoutJSの代わりにKnockout MVCを使用するべきではありませんが、KnockoutJSのほかに使用する必要があります。いずれの場合も、Javascriptと少なくともKnockoutJSの基本を理解することは必須です。
著者がKnockoutMVCの開発を続けてほしいと思います。これらの良い点に加えて、それをさらに強力にするいくつかの機能と改良があります。
于 2013-12-11T17:46:52.717 に答える
4
.Net MVCパターンでは、ビューモデルはすでに各ビュー/部分ビューにタグ「@modelyourmodel」で明確にマークされています。これにより、開発者はこのビューで何が行われるかを理解できます。
knockout.js MVVMパターンを使用する場合、ビューに「data-bind」などのタグを除いて、.Netビューモデルが表示されない可能性があります。これにより、ビューとコントローラーが分離され、チーム内の新しい開発者のためにロジックを追跡することが困難になります。
私は、knockoutMVCがそのような困難を解決し、システムの保守と理解を困難にする多くのjavascriptコードを節約できると信じています。
knockoutMVCを使用すると、C＃コードであるため、追跡と保守が容易なサーバー側のビューモデルの適用に引き続き設計が固執します。
ビジネスプロジェクトの場合、マネージャーは常に、開発、保守、アップグレード、理解が容易で、収益を上げるために迅速に提供することに重点を置く必要があります。
パフォーマンスを少し犠牲にしますが、シンプルにします。クライアント側とサーバー側での一貫性が重要なポイントになります。Javascriptはメンテナンスの大きな問題です。
ビューモデル全体をサーバー側に送り返すことは本当に重要ですか？もしそうなら、大きなモデルをいくつかの小さなモデルに分割することができます。
于 2013-11-17T18:28:24.023 に答える
2
komvcによって生成された関数を使用していない場合でも、パフォーマンスは維持されます。Nigelが言ったように、最初のページ生成はサーバーで生成する必要があります。いつでもユーザースクリプトを追加して、サーバーに戻る必要のないクライアント側の関数を作成できます。これは、開発者に少しの生産性を与えるツールです。パフォーマンスに関するWebフォームとの比較は確かに誇張されています。皆さん、それはあなたがあなたの締め切りに間に合わせるのを確かに助ける1つのツールです。
于 2013-10-16T17:37:00.137 に答える
1
ノックアウトMVCに比べて書くのは少し複雑ですが、ノックアウトjsを優先して2セントを追加します。再利用性に関しては、大きなメリットがあります。クライアントコードは、他のテクノロジーとも調和して機能します。
セキュリティの観点はさておき、私は個人的に、ノックアウトjsはasp.net MVCを複雑にする方法であり、asp.net webapiなどの純粋なRESTfulアプリケーションでそのまま使用する必要があると感じています（ノックアウトjs）。
于 2014-03-27T11:58:02.330 に答える
1
Knockout MVCは、ASP .NET MVCの強力な拡張機能であり、Javascriptを使用せずに開発者向けのfluentAPIを使用し、重複した反復コードを多数削除して、Webサイトクライアント機能を.NETプロジェクトに直接実装できます。
ノックアウトMVCは、ASP .NET MVCかみそりのコーディングと同じであり、余分な手間をかけずにクライアント機能を利用できます。
ビューモデルとバインディングコードの行をコーディングする必要はありません。
私はほとんどのWebサイトでkoMVCを使用しており、開発時間の短縮、簡単なメンテナンス、最小限の学習曲線は大きな見返りです。
彼らのウェブサイトをチェックして、いくつかの実例を試してみることをお勧めします。http://knockoutmvc.com
あなたがそれに恋をするのにそれほど時間はかかりません。
于 2016-11-23T05:10:44.250 に答える
0
MVCは、モデル、ビュー、コントローラーの3つのコンポーネントに分かれるアーキテクチャパターンです。
フレームワークのデータバインディングではコントローラーを使用する必要があるため、KnockoutJSはMVCアーキテクチャで最適に機能します。フロントエンドに重点を置いたAngularJSなどのフレームワークがあるため、MVVMアーキテクチャパターン（モデル、ビュー、ビューモデル）でより適切に機能します。それらのデータバインディング機能は、バインディングの範囲を縮小するコントローラーの使用も必要としません。
于 2018-02-09T15:28:46.973 に答える