1

Knockout コンポーネント + Asp.Net MVC を使用する場合、次のスニペットは良い方法ですか? 私が見逃しているかもしれない欠点はありますか？

基本的に、Razor サーバー側レンダリングを使用して、ko コンポーネントの依存関係 (主に初期データ) の一部を注入しています...

コードスニペット：

<my-component params="{ 
    foo: '@Model.FooProperty',
    bar: '@Model.BarProperty',
    baz: @Json.Encode(@Model.SomeArray)
}"> </my-component>

編集：

@Quango が指摘する文字列エスケープの問題を回避するために、次のヘルパーを実装しました。

public static stringEscapeString(this HtmlHelper helper, string value)
{
   return HttpUtility.JavaScriptStringEncode(value, true);
}

使用法：

<my-component params="{ 
        foo: '@Html.EscapeString(Model.FooString)', ...
4

1 に答える 1

0

私の仕事では、ASP.NET MVC プロジェクトで Knockout を使用しており、この悪い習慣を考慮しています。しかし、この理由はあなたには当てはまらないかもしれません。これは自分で判断する必要があります

  • HTML のキャッシュなし (挿入された値が変更される可能性があるため)
  • HTML と JavaScript をバンドルしない (上記と同じ)
  • 同じ問題に対して異なるソリューションを混在させることは、特に (大規模な) チームでは、悪い習慣になる可能性があります。基本的に、ノックアウトを選択したので、JavaScript で必要なデータを取得し、ビューでバインドするのが「通常の」方法です。これが通常行うことである場合は、データが（おそらく）静的であるという理由だけで、ここで本当に例外を作成するかどうかを検討してください。これがすべて数バイトの節約に関するものである場合は、すべての HTML と JavaScript を縮小されたバンドルで提供するようにバランスをとることを想像してみてください。これはクライアントにもキャッシュできます。
  • 後でデータを上書きする方法はありません。基本的にサーバーによって「ハードコード」されています。
  • コードの移植性が低下します。Razor 構文は基本的に、フロントエンドを選択したバックエンド テクノロジに結合します。これが長期的なプロジェクトである場合は、数年後に別のバックエンド技術がより良い代替手段であると判断する可能性がわずかにあるかどうかを検討してください。これを可能にするためだけにフロントエンド。

これらの理由はどれもすべてのプロジェクトに関連するものではないため、コンテキストに大きく依存します。考えられる限りのデメリットを挙げてみました。

于 2016-02-05T12:42:17.640 に答える