Knockout JSの代わりにKnockout MVCを使用する理由はありますか？
別のユーザー 推奨 Knockout MVC いくつかのAJAX投稿の問題を処理するために。少し読んで、周りのラッパーであることがわかりました- Knockout JS 。だから、2つの本当の違いは何だろう？ Knockout JSKnockout MVC が存在するので、気にする必要がありますか？片方はもう片方ですか？
ノックアウトMVCはWebFormsのろくでなし。すべてのviewmodelメソッドをコントローラーアクションにルーティングします。つまり、発生したすべてのことはサーバーにバウンスして戻らなければなりません。 CLIENT SIDE MVVMを目的とするノックアウトのようなフレームワークを誰かが採用し、すべての機能に対してサーバーを呼び出すように強制する理由を理解できません。
さらに、サーバーでこれらのメソッドを実行すると、すべての関数呼び出しに対して、viewmodel全体をサーバーに渡し、クライアントに戻す必要があります。 これは非常に無駄です。
Knockout MVCを使用するということは、javascriptを記述する必要がないという利点のために、クライアント側コードのパフォーマンス上の利点をすべて犠牲にすることを意味します。同じトレードオフWebFormsが作成されました。それは良いものではありません。これはアンチパターンです。
Knockout MVCが明日死ぬなら、ウェブはより良い場所になります。
私はこの質問に出くわしましたが、これにはかなり否定的な反応があります。私はすぐに2セントの価値を追加します。
KnockoutJSを使い始めたばかりです。 ASP.NET MVCアプリを構築しているので、Knockout MVCのようなものを使用することは論理的に思えました。ほとんどの場合、それは素晴らしいアイデアのようです。私が知っていて大好きな.Net機能を使用して同じことを行うことができれば、ページを通してjavascriptと<!-- ko -->コメントを書くことに時間を費やしたくありません。
そうは言っても...はい、現時点ではKMVCには制限があります。モデル全体をサーバーに送り返すことは大きなものです。それで、私がやったことは、私自身のknockout-mvcのフォークを始めました。現時点では、必然的に変更が急いでいます。しかし、今では次のことができます。
- サブコンテキストの作成（ビューモデルの完全に異なるモデルまたはコンポーネントを使用）
- サーバーを呼び出すときに、モデルの選択した部分を戻す
- 送信されたものとは異なるモデルがコールから返されることを期待する
- ajax呼び出しの周りでイベントを発生させる
- より多くのhtml5入力タイプをサポート
- ヘッダーを介してサーバーに偽造防止トークンを渡す（ajax呼び出しの場合）
- おそらくもっと忘れてしまった
私はすぐに戻って、私がやったことを本当にきれいにしたいと思っています。うまくいけば、著者はこれらの変更を自分のコードに含めます。そうでない場合、私は自分のフォークを続けていくと思います。いずれにせよ、トンネルの終わりに光があります。 KMVCは現状のままで作業が必要になる場合がありますが、このコンセプトは間違いなく実行する価値があると思います。
絶対に思う
Knockout MVCが明日死ぬならば、ウェブはより良い場所になるでしょう。
少し過酷でした。
編集：
私はコメントを見ていましたが、元の質問が何であるかをもう一度見ました。それが終わったら、もう少し答えに追加する必要があると思います。
最初に、元の質問はKnockout JSの代わりにKnockout MVCを使用する理由はありますか？ KnockoutJSをASP.NET MVCアプリと簡単に統合できます。これは、KnockoutJSタグを生成するために、おなじみの、厳密に型指定された構造を使用することにより主にこれを行います。 KnockoutJSの代替品ではありません。必ずKnockoutJSを使用してください。問題は、Knockout MVCも使用するかどうかです。
そうは言っても、利用可能なすべてのツールのさまざまな側面をいつ使用するかを選択する開発者として、選択は依然としてあなた次第です。サーバーへの完全なリクエストを実行して機能の特定の側面を処理する場合は、それを実行します。 Ajaxリクエストを実行してデータを取得/更新する場合は、それを実行します。機能を純粋にクライアント側で実行する場合は、それを実行します。
Knockout MVCを使用しても、KnockoutJSを最大限に活用できません。 Knockout MVCを使用しても、クライアント側の機能を必要なだけ処理するための追加のJavaScriptを書くことはできません。 Knockout MVCがサーバーへのAjaxコールバックを生成するためのショートカットを提供するという理由だけで使用しないわけではありません。ただし、アプリケーションがデータを永続化する場合は、ある時点で家に電話する必要があります。
Apacheを使用して静的なHTMLファイルとスクリプトファイルを提供するのと比較して、ASP.NET MVCを使用してアプリケーションバックエンドを構築する理由があります。 Knockout MVCを使用すると、KnockoutJSの統合を支援するために、引き続き同じ利点を活用できます。
ティルシウスの答えは否定的すぎると思う。 Knockout MVCはまだ初期の開発段階にありますが、私が見ることができるのは、いくつかの利点があり、たとえばWebformsよりもサーバーの負荷が少ないことです。可視性の依存関係は、関数を使用する場合にのみサーバーへの呼び出しが行われる場合にのみ、クライアント上で完全にハンドルを取得します。複雑なデータ構造を扱う場合は、とにかくサーバーを経由する必要がある場合があるため、Knockout MVCを使用すると、多くのAjax処理を自分で作成する手間を省くことができます。
常にモデル全体をやり取りするため、自分で作成するのではなくオーバーヘッドが発生します。しかし、私はそれを完全に消すつもりはありません。特に、将来の複雑な検証のために適切なクライアント側の処理を取得する場合。
ノックアウトmvcについて少し検索した後、この投稿に出会いました。私はネットワーク帯域幅の浪費に同意していますが、そのコード行には非常に魅了されています：
@{
var ko = Html.CreateKnockoutContext();
}
これは、ノックアウトビューモデルを生成するためのきちんとしたクリーンな方法です。誰もがその機能のためだけに、すべてのロジックをサーバー側に移動せずにノックアウトMVCを使用しましたか？
Knockout.jsの優れた点は、HTMLを生成するためにサーバーがチャンクしなければならないビュー全体をプッシュすることなく、サーバーからJSONをやり取りするだけでアプリケーションを提供できることです。
再びサーバーに戻すことは非常に直感に反するようです！興味がある場合は、そもそもバインディングを実現するために、カミソリ構文を使用した方が良いでしょう。
私が提案するのは、knockout.jsを使用してバインディングを行い、これが目的の場合は、サーバーではなくクライアントでバインディングが行われるようにすることです。ビューをサーバー上のデータバインドにするには、razorを使用します。
さらに、knockout.jsは、クライアント側のデータの表示/削除/挿入/更新、およびクライアント側のデータ計算に非常に優れています。実際のビジネスロジックがそれと同じくらい簡単な場合は、knockout.jsを直接適用する必要があります。
真実は、ビジネスロジックは必ずしもそのように単純ではないということです。たとえば、クライアントがビューに新しいレコードを挿入する場合、システムはユーザーの認証を確認し、ビジネスロジックや式などに基づいて新しく作成されたオブジェクトのデフォルト値を設定する必要があります。データベースデータに基づくロジック。
開発者は、必要なすべてのビジネスロジックをJava knockout.jsビューモデル内のスクリプトメソッドに変換できます。しかし、この方法では、デザインはビジネスロジックの集中処理ルールに違反します。
このような設計では、保守が悪夢になります。
要約、どのフレームワークの選択がビジネス要件に本当に依存するか。時には、パフォーマンスが最初の考慮事項ではありません。
また、Knockout MVCライブラリを使用した多くの優れたユースケースを見ることができます。 KnockoutJSをMVC Webアプリに統合することはほとんどできませんでした。これは、たとえば@ChinaHelloWorldによって指摘された理由のためです。以下に、非常に役立つ例をいくつか示します。
- 強く型付けされたバインディング
私はニースの強く型付けされたHTMLヘルパーメソッドが好きでしたが、KnockoutJSのセットアップに関してはまったく使い物にならず、面倒です。できる最善の方法は、ヘルパーメソッドの追加パラメーターを使用してバインド属性を手動でアタッチすることですが、マジックストリングを再度使用する必要がありました。 Knockout MVCが提供する、強く型付けされたC＃式ベースのバインディングを持つ入力およびその他の要素を作成するためのヘルパーが好きです。ただし、ここでは、生成されたフィールドのname属性が欠落していることに言及したいので、少し調整する必要がありました。
- 厳密に型指定されたバインディング構文（種類）
純粋な文字列バインディングを使用する場合、つづりを間違えたり、適用したいバインディングの正しい形式を正確に知らない可能性が常にあります。 Knockout MVCとVS IntelliSenseの流れるようなAPIを使用すると、正しいバインディングを簡単に適用できます。
- （ほぼ）計算されたC＃プロパティから計算されたバインディングへの自動変換
小さな[Computed]属性を適用するだけで、Knockout MVCは正しいKnockoutJS構文で対応するバインディング式を生成できます。これも非常に便利だと思います。
- ビューモデルコードの重複なし
古典的な方法では、C＃コードでビューモデルクラスを作成し、次に（ほぼ）JSで同じビューモデルコード（オブザーバブルを使用）を作成する必要がありました。まあ、それは私にとってイライラさせられ、Knockout MVCで使用されている技術を見たとき、私は非常に幸せになりました。ただし、非常に複雑なビューモデル（ネストされたビューモデル、コレクションなど）で使用できるように、また必要なカスタムJSメソッドまたは計算されたオブザーバブルでマップされたKnockoutビューモデルを拡張できるように、少し調整する必要がありました。
少なくとも4つの非常に良い点があります。そして、ビューモデルの往復について：誰もがKnockout MVCのサーバー側の処理メカニズムを使用する必要があるとは誰も言いませんでした。サーバー上で実際に処理する必要のある複雑なビジネスロジックがある場合にのみ、これも使用しません。ただし、ほとんどの場合、Knockout MVCは、MVCビューとKnockoutJSのバインディングとセットアッププロセスを単純化するためのものです。したがって、上記の悪い意見をよく理解していません。これらの意見を書いた人は、少なくともKnockout MVCの基本概念を学ぶ努力をしなかったと思います。明確にKnockoutJSの代わりにKnockout MVCを使用する必要がありますが、KnockoutJSを使用する必要がありますどのような場合でも、Javascriptと少なくともKnockoutJSの基本を理解することは必須です。
筆者がKnockout MVCの開発を続けて欲しいと思います。これらの優れた点に加えて、実際にさらに強力になる機能と改良点があるからです。
.Net MVCパターンでは、ビューモデルは既にタグ "@model yourmodel"で各ビュー/部分ビューに明確にマーク付けされているため、開発者はこのビューで何を行うかを理解できます。
Knockout.js MVVMパターンを使用する場合、ビューの「data-bind」などのタグを除いて、.Netビューモデルが表示されない可能性があります。これにより、ビューとコントローラーが切り離され、チームの新しい開発者向けに特別にロジックを追跡するのが難しくなります。
KnockoutMVCはそのような困難を解決し、システムの保守と理解を困難にする多くのJavaScriptコードを保存できると信じています。
KnockoutMVCを使用すると、C＃コードであるため追跡および保守が容易なサーバー側ビューモデルの適用に設計が引き続きこだわります。
ビジネスプロジェクトの場合、マネージャーは常に、開発、保守、アップグレード、理解、および迅速な納品に注力する必要があります。
パフォーマンスを少し犠牲にしますが、シンプルにするために、クライアント側とサーバー側の一貫性が重要なポイントになります。 Javascriptは大きなメンテナンスの問題です。
ビューモデル全体をサーバー側に送り返すことは本当に問題ですか？もしそうなら、大きなモデルをいくつかの小さなモデルに分割できます。
Komvcによって生成された関数を使用していない場合でも、パフォーマンスは維持されます。ナイジェルが言ったように、最初のページ生成はまだサーバー生成でなければなりません。いつでもユーザースクリプトを追加し、サーバーに戻る必要のない関数をクライアント側で作成できます。開発者に少し生産性を与えるツールです。パフォーマンスに関するWebフォームとの比較は確かに誇張されています。皆さん、それはあなたの締め切りを守るのに役立つツールの1つです。
Knockout MVCは、ASP .NET MVCの強力な拡張機能です。これにより、Javascriptを使用せず、多くの重複した反復コードを削除する開発者向けのfluentAPIを使用して、.NETプロジェクトにWebサイトクライアント機能を直接実装できます。
knockout MVCは、コーディングASP .NET MVC剃刀と同じであり、クライアントの機能を手間をかけずに取得できます。
ビューモデルとバインディングコードの行をコーディングする必要はありません。
ほとんどのWebサイトでkoMVCを使用していますが、開発時間の短縮、メンテナンスの容易さ、および最小の学習曲線は大きな見返りです。
彼らのウェブサイトをチェックして、いくつかの実例を試してみることをお勧めします。 http://knockoutmvc.com
あなたがそれに恋をするのに時間はかかりません。
ノックアウトMVCに比べて書くのは少し複雑ですが、再利用性に関しては大きなメリットがありますが、2セントを追加して、ノックアウトjjsを支持します。クライアントコードは、他のテクノロジーとも調和して機能します。
セキュリティの観点を別にすれば、ノックアウトjsはasp.net MVCを複雑にする方法であり、asp.net webapiなどの純粋なRESTfulアプリケーションでそのまま使用する必要があります（knockout js）。
MVCは、Model、View、Controllerの3つのコンポーネントに分かれるアーキテクチャパターンです。
フレームワークのデータバインディングにはコントローラーの使用が必要なため、KnockoutJSはMVCアーキテクチャで最適に動作します。フロントエンドにより重点を置いたAngularJSなどのフレームワークがあり、MVVMアーキテクチャパターン（モデル、ビュー、ビューモデル）との連携が向上しています。データバインディング機能では、バインディングの範囲を縮小するコントローラーを使用する必要もありません。