JSONの代わりに生成されたHTMLを返すのはなぜ悪い習慣ですか？またはそれは？
JQueryまたは他の同様のフレームワークを使用して、カスタムURL/WebサービスからHTMLコンテンツをロードするのは非常に簡単です。私はこれまで何度もこのアプローチを使用してきましたが、パフォーマンスは満足のいくものでした。
しかし、すべての本、すべての専門家は、生成されたHTMLの代わりにJSONを使用するようにしようとしています。 HTMLよりもはるかに優れているのはなぜですか？
非常に高速ですか？
サーバーの負荷は非常に小さくなっていますか？
一方、生成されたHTMLを使用する理由がいくつかあります。
- それは単純なマークアップであり、多くの場合、JSONと同じくらいコンパクトであるか、実際にはJSONよりコンパクトです。
- エラーが発生しにくいのは、マークアップだけでコードを取得しないためです。
- ほとんどの場合、プログラムする方が高速になります。これは、クライアント側で個別にコードを記述する必要がないためです。
あなたはどちら側にいますか、そしてなぜですか？
私は実際には両側に少しいます：
- Javascript側で必要なものがdataの場合、JSONを使用します
- Javascript側で必要なものがpresentationで、その上で計算を行わない場合、通常はHTMLを使用します
HTMLを使用する主な利点は、ページ全体をAjaxリクエストから返されたもので置き換える場合です。
- JSでページの一部を再構築するのは（かなり）難しい
- おそらく、サーバー側にテンプレートエンジンが既にあり、最初にページを生成するために使用されていました...再利用しませんか？
私は通常、少なくともサーバー上では、物事の「パフォーマンス」側を実際に考慮していません。
- サーバー上で、HTMLまたはJSONの一部を生成しても、それほど大きな違いは生じません。
- ネットワークを通過するもののサイズについて：まあ、おそらく何百キロバイトのdata/htmlを使用しないでしょう...転送するものにgzipを使用することが最大の違い（HTMLとJSONを選択しない）
- ただし、考慮すべきことの1つは、クライアントでHTML（またはDOM構造）を再作成するために必要なリソースですJSONデータ... HTMLの一部をページにプッシュすることと比較してください;-)
最後に、間違いなく重要なことが1つあります。
- HTMLとしてページに挿入するために必要なJSがJSON +コードとしてデータを送信する新しいシステムを開発するのにどれくらいかかりますか？
- HTMLを返すだけでどれくらいかかりますか？また、既存のサーバー側コードの一部を再利用できる場合、どのくらいかかりますか？
そして、別の答えに答える場合：ページの複数の部分を更新する必要がある場合、いくつかのHTML部分をグループ化する1つの大きな文字列内にそれらのすべての部分を送信し、関連するJSのパーツ。
たとえば、次のような文字列を返すことができます。
<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->
それは本当によく見えませんが、それは間違いなく便利です（私はそれを何度も使用しましたが、ほとんどはHTMLデータが大きすぎてJSONにカプセル化できない場合）：プレゼンテーションが必要なページの部分にHTMLを送信し、データが必要な状況にJSONを送信しています...
...そして、それらを抽出するために、JSサブストリングメソッドがトリックを行います;;）
私は主にここで述べた意見に同意します。私はそれらを次のように要約したかっただけです。
HTMLをクライアント側で解析して計算を行う場合、HTMLを送信するのは悪い習慣です。
最終的にJSONをページのDOMツリーに組み込むだけの場合は、JSONを送信するのは悪い習慣です。
まあ、
私はこのように物事を分けるのが好きなまれな人の一人です。 -クライアントは、データの表示（表示）と操作（モデル）を担当します。
そのため、サーバーはモデルの配信に集中する必要があります（この場合、JSONの方が優れています）。これにより、柔軟なアプローチが可能になります。モデルのビューを変更する場合は、サーバーから同じデータを送信し続け、そのデータをビューに変更するクライアント（javascriptコンポーネント）を変更するだけです。たとえば、モバイルデバイスとデスクトップアプリにデータを配信するサーバーがあるとします。
また、このアプローチは生産性を向上させます。サーバーとクライアントのコードを同時に構築できるため、jsからPHP/Javaに切り替え続けると起こるフォーカスを失うことはありません。 _ /など.
一般的に、ほとんどの人はjsをマスターしていないため、サーバー側で可能な限り実行することを好むので、できる限り回避しようとします。
基本的に、Angularに取り組んでいる人たちと同じ意見です。私の意見では、これがWebアプリの未来です。
何か面白いことがあると思います。完全なビューを一度だけロードするアプリケーションを開発しました。それ以降は、ajaxのみを使用してサーバーに返信しました。 1ページだけロードする必要があります（ここでの私の理由は重要ではありません）。おもしろいのは、JavaScriptで操作するデータと、表示する部分ビューを返す必要があるという点です。これを2つの別々のアクションメソッドへの2つの呼び出しに分割することもできましたが、もう少し楽しいことをすることにしました。
見てみな：
public JsonResult MyJsonObject(string someData)
{
return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}
RenderPartialViewToString（）とは何ですか？ここにあるのは、この小さなクールなナゲットです。
protected string RenderPartialViewToString(string viewName, object model)
{
ViewData.Model = model;
using (StringWriter sw = new StringWriter())
{
ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
viewResult.View.Render(viewContext, sw);
return sw.GetStringBuilder().ToString();
}
}
これについてはパフォーマンステストを行っていないので、JsonResultのアクションメソッドとParticalViewResultのアクションメソッドを呼び出すよりも多少オーバーヘッドが発生するかどうかはわかりませんが、それでもかなりクールだと思いました。部分的なビューを文字列にシリアル化し、Jsonとともにパラメーターの1つとして送信します。次に、JQueryを使用してそのパラメーターを取得し、適切なDOMノードに追加します:)
あなたが私のハイブリッドについてどう思うか教えてください！
応答にさらにクライアント側の処理が必要ない場合、HTMLは問題ありません。 JSONを送信すると、そのクライアント側の処理のみが強制されます。
一方、すべての応答データを一度に使用したくない場合はJSONを使用します。たとえば、一連の3つのチェーン選択があり、1つの選択値によって、2番目の値の設定に使用される値が決まります。
IMVでは、データの表示からデータを分離することがすべてですが、Pascalの場合は、必ずしもその分離がクライアント/サーバーの境界を越えて行われるとは限りません。その分離が既に（サーバー上で）あり、クライアントに何かを表示したい場合、JSONを返してクライアントで後処理するか、単にHTMLを返送するかは、完全にニーズに依存します。一般的なケースでHTMLを返送するのが「間違っている」と言うのは、IMVの文にはあまりにも包括的です。
私の意見ではベストプラクティスである、きれいに分離されたクライアントが必要な場合は、javascriptによって作成されたDOMの100％を持つことが理にかなっています。 UIの構築方法をすべて知っているMVCベースのクライアントを構築する場合、ユーザーは1つのjavascriptファイルを1回ダウンロードし、クライアントにキャッシュします。初期ロード後のすべてのリクエストはAjaxベースであり、データのみを返します。このアプローチは私が見つけた中で最もクリーンであり、プレゼンテーションをきれいに独立してカプセル化することができます。
サーバー側は、データの配信に集中します。
したがって、製品がページのデザインを完全に変更するように要求する明日は、DOMを作成するソースJSだけが変更されますが、既存のイベントハンドラーを再利用できます。
JSONは非常に汎用的で軽量な形式です。クライアント側のテンプレートパーサーデータとして使用し始めたときに、その美しさを発見しました。説明しましょう。サーバー側でsmartyとビューを使用する前（サーバー負荷が高い）に、カスタムjquery関数を使用し、クライアントブラウザーをテンプレートパーサーとして使用して、すべてのデータをクライアント側でレンダリングします。サーバーのリソースを節約し、ブラウザは毎日JSエンジンを改善します。したがって、クライアント解析の速度は今のところ重要な問題ではありません。さらに、JSONオブジェクトは通常非常に小さいため、クライアント側のリソースをあまり消費しません。サーバーの負荷が非常に高いため、すべてのユーザーのサイトが遅くなるよりも、ブラウザーの遅いユーザー向けに遅いWebサイトを使用することを好みます。
一方、サーバーから純粋なデータを送信すると、プレゼンテーションから抽象化されるため、明日、それを変更したり、データを別のサービスに統合したりする場合は、はるかに簡単に行うことができます。
ちょうど私の2セント。
UIによっては、DOMの2つ（またはそれ以上）の異なる要素を更新する必要がある場合があります。応答がHTMLの場合、それを解析して何がどこに行くのかを把握しますか？または、JSONハッシュを使用できます。
それを組み合わせて、JSON w/html dataを返すこともできます:)
{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }
HTMLには、タグ、スタイルシートなどの多くの冗長な表示されないデータがあります。したがって、JSONデータに比べてHTMLサイズが大きくなり、ダウンロードとレンダリングに時間がかかり、ブラウザが新しいデータのレンダリングに忙しくなります。
一般的に、jsonの送信は、リスト、ツリービュー、オートコンプリートなどのサーバーからの情報をリクエストするJavaScriptウィジェットがある場合に行われます。これは、JSONを送信するときのデータです。これは、解析されてそのまま使用されるデータです。ただし、HTMLを表示するだけの場合は、サーバー側で生成してブラウザに表示するだけで済むため、作業が大幅に軽減されます。ブラウザはinnerHTML = ""でHTMLをdomに直接挿入するように最適化されているので、これを間違えることはありません。
状況に依存します。
JSONを避けることが不可欠な場合があります。たとえば、プログラマがjsでのプログラミングに問題がある場合。
私の経験から、インラインJSONよりもajaxサービスを使用したほうがよいことがわかりました。
遅かれ早かれ、jsが問題になります
クライアント側で何らかの計算を実行する必要がない限り、ほとんどの場合、Html応答で十分です。
デザインの構造に依存すると思います。JSONを使用するほうがHTMLよりもセクシーですが、問題は、それをどのように処理して簡単に維持できるかということです。
たとえば、サイト全体の同じhtml/styleを使用するリストページがあるとします。HTMLのこれらの部分をフォーマットするグローバル関数を記述し、JSONオブジェクトを関数に渡すだけです。