Web APIを使用した純粋なフロントエンドJavaScriptとajaxを使用したMVCビュー
これは、最近のWebアプリケーションの分割方法に関する人々の考えについての議論でした。
すべてのビューとコントローラーを備えたMVCアプリケーションの作成に慣れています。私は通常、完全なビューを作成し、これをページ全体のリクエストでブラウザに返します。ただし、すぐに入力したくない特定の領域がなく、DOMページのロードイベントを使用してサーバーを呼び出して他の領域をロードする場合を除きます。 AJAXを使用します。
また、ページの部分的な更新については、MVCアクションメソッドを呼び出し、HTMLフラグメントを返します。これを使用して、ページの一部を設定できます。これは、最初のページの読み込みを遅くしたくなかった領域、またはAJAX呼び出しでうまく適合した領域です。1つの例は、テーブルページングの場合です。次のページでは、ページ全体を更新するのではなく、AJAX呼び出しがその情報を取得した場合に優先します。ただし、AJAX呼び出しでもHTMLが返されます断片。
私の質問です。私は純粋なフロントエンドの背景ではなく.netの背景から来ているので、この古風な考えは私のものですか？
私が協力しているインテリジェントなフロントエンド開発者は、MVCビューで多かれ少なかれ何もしないことを好み、むしろフロントエンドですべてを行います。ページに入力するWeb API呼び出しまで。そのため、HTMLを返すMVCアクションメソッドを呼び出すのではなく、標準オブジェクトを返し、JavaScriptを使用してページのすべての要素を作成することを好みます。
フロントエンドの開発者の方法は、クライアント側の検証を含め、MVCモデルの検証で通常得られる利点がすべてなくなることを意味します。また、厳密に型指定されたhtmlテンプレートなどを使用してビューを作成することで得られるメリットはすべて失われます。
これは、フロントエンドとバックエンドの検証に同じ検証を記述する必要があることを意味すると思います。 JavaScriptには、DOMのさまざまな部分をすべて作成するための多くのメソッドも必要です。たとえば、テーブルに新しい行を追加するとき、通常はMVCパーシャルビューを使用して行を作成し、これをAJAX呼び出しの一部として返します。テーブル。純粋なフロントエンドの方法を使用することにより、JavaScriptはapi呼び出しからの行のオブジェクト（たとえば、製品）を受け取り、そのオブジェクトから行を作成します。テーブル行。
問題のWebサイトには、管理、フォーム、製品検索など、さまざまな領域があります。私が考えていないWebサイトは、単一ページアプリケーションの方法で構築する必要があります。
これについてのみんなの考えは何ですか？
フロントエンド開発者とバックエンド開発者からの意見に興味があります。
私はまた、すべての新しいWebアプリがSPAである必要があることについても少し懐疑的ですが、クライアント側での経験の大部分で私がジェネラリストとして100％販売されていることの1つは、生のハンドオフを提供するサービス指向アーキテクチャーです。 HTMLではなくデータをクライアントに送信することは、サーバーから事前に作成されたページ/ビューをロードし、ページのロード後にデータを使用して多くの動的な処理を実行するか、JavaScriptでほぼすべてを100％構築するかを決める方法です。
これがクライアント側の開発者にとって好ましい理由は、データベースにHTMLを望まない理由とほとんど同じです。たとえばHTMLを渡されたときにテーブルを再利用したい場合、クライアント側の開発者は何をするべきですか？クライアント上でそれをすべて処理するパフォーマンスコストは、別のサーバーにそれを実行するように要求するのに比べて取るに足りません。また、HTML構築はJSランドでかなりカバーされています。データを並べ替え、そこから新しいHTMLテーブルの行を作成することは、経験豊富なクライアント側の開発者にとっては非常に簡単な作業です。
また、100％キャンバスまたはまったく異なるHTML構造のウィジェットを実装するなど、エキゾチックな何かを実行する必要がある別のデバイスのフロントエンドへのバックエンドアーキテクチャの用途は何ですか？厳密にプレゼンテーションを微調整するために、クライアント側の開発者がビジュアルスタジオをロードするか、バックエンドの開発者のドアをノックする必要があるのはなぜですか？
厳密に型指定されたテンプレートの検証が失われることについての懸念については、有能なクライアント側の開発者を扱っている場合は、.NETフレームワークも、より石炭に近いビジュアルスタジオツールも見つからないと私が信じる整形式の有効なHTMLについて、ダイヤモンドから粉々にアナルを破壊する。
フルスタックの観点から見ると、ビジネスやアプリのロジックのために釣りをする必要がないことを意味しているので、いくつかのyutzがテンプレートレイヤーにドロップすることに決めました。ユーザーごとの負荷は言うまでもありませんが、多くの場合、最新のコンピューターを備えた最新のブラウザーでのユーザーの負荷エクスペリエンスを実際に改善しています。
また、すべてのプレゼンテーションのものから完全に分離した方が、バックエンドアーキテクチャについて説明する方が簡単だと思います。データを取得してHTMLにマッシュする必要はもうありません。これを組み合わせて、実装に依存しないデータ構造を作成します。これは、反対側で何が行われるかよりも、一般的な使用に関係するものです。 IMO。これは、データがプロセスの最後から2番目のステップではなく最終目標になり、無関係な懸念がワイヤーを交差させる機会が少なくなるため、処理方法の一貫性が高まる傾向があります。
私は非常に主観的な2ペニーの価値を提供します（価値があるので;））。これには正しい答えも間違った答えもありません。たとえば、ポイントに加えて、多くの現実的な考慮事項があります。
- 社内で関連する経験がありますか？クライアント側駆動型アプリの構築は、完全に異なるスキルセットを持つ主にサーバー駆動型アプリとは大きく異なります。
- どのくらいの時間がかかり、どのブラウザをサポートする必要がありますか？ -クライアントで行う作業が多ければ多いほど、直面するブラウザーの問題も多くなります。 IE8は痛みを伴い、JavaScriptのパフォーマンスはかなり低下しますが、XP/IEセットアップを実行している企業はたくさんあります。
- ユーザーがサイトを表示する予定のデバイスは何ですか？ Chrome-の最新バージョンではJavaScriptの解析と実行が高速である可能性があります-しかし、それは古いモバイルデバイスでは特に、大量のビジネスロジックが含まれているJavaScriptではありません
- 初期読み込みはどのくらい重要ですか？サーバーテンプレートはクライアントテンプレートよりも高速です
このリストは決して網羅的ではなく、クライアントサイドのバッシングのように聞こえますが、これは私の意図ではありません。フロントエンドに重点を置いてサイトを作成しました。
私にとってそれは本当にユーザーエクスペリエンスとAPIの再利用性に帰着します。これらのそれぞれに対処する。
アプリを作成したり、APIを提供したりする場合、.Net APIプロジェクトを使用することには多くの意味があります。これにより、ロジック、チェック、実装のクロスプラットフォームが形成されます。このシナリオでは、完全なクライアント側のアプローチが有利な場合があります。APIは個別に維持でき、アプリケーションへのインターフェースを提供するだけです。ロジックを修正して快適にリファクタリングでき、インターフェースを同じに保つ必要があります。すべて同じバックグラウンドコードを使用して、さまざまなメディア用のさまざまなアプリケーションを簡単に作成できます。
（私の意見では）純粋なフロントエンドソリューションの最も強力な議論は、ユーザーエクスペリエンスです。
（すべての欠点を考慮すると）純粋なJavaScriptブラウザーアプリケーションは、従来のWebサイトの使いやすさとユーザーエクスペリエンスを大幅に向上させますか？
ネイティブアプリケーションのように機能するサイトを作成する場合。私は答えが明白なイエスであると主張します。ただし、ほとんどのサイトはこのクリーンカットではありません。そのため、非常に動的なインターフェイスが個々のユーザーワークフローにメリットをもたらすかどうかを評価する必要があります。
私はこれをかなり実際的な見方をしていますが、どちらでも問題でもありません。 JavaScriptは明らかにサーバーテクノロジと一緒に非常に楽しく機能し、どちらか一方を選択する必要はありません。すべてのサイトが単一ページのWebアプリではありません。必要と思われる場合は改善してください。
フロントエンドのヘビーアプリケーションとは愛憎関係にあります。
一方で、私はJavaScriptを書くのが好きで、実行環境としてブラウザーが好きです。
一方、どちらもエンジンに穴の開いたF1レースカーのように感じます。つまり、C＃とJavaScriptの間のビジネスロジックの重複を防ぐことができますか。もしそうなら、あなたが価値があると思うビューを生成するためにどんな方法でも使用してください。ビジネスロジックを2つの言語で複製している場合、JavaScriptを記述したいだけのフロントエンドの開発者がいて、全体像がよくわかりません。
技術的な違いについては：
パーシャルをレンダリングしてクライアントに配信する：
- 簡単で迅速な実装
- バックエンドビジネスロジックがフロントエンドで複製されるのを防ぎます
- ブラウザへのHTTPペイロードがはるかに大きくなる可能性があります。高帯域幅接続のデスクトップでは問題ありません。ラッシュアワーの電車に乗って60mphでトラックを減速しているときに、弱い携帯電話で非常に悪い。他の1,000台の携帯電話が1つのセルタワーから同時に切断し、次のセルタワーに再接続しようとしている。
JSONの配信とクライアント側テンプレートのレンダリング：
- その結果、HTMLよりもHTTPペイロードが小さくなり、信頼性の低いネットワーク接続や遅いネットワーク接続に対してアプリケーションの応答性が向上する可能性があります。
- 多くのJavaScriptテンプレート言語は完全に機能しています。つまり、HTMLを生成するためだけにバックエンドを必要としない
時々私は新しいJavaScriptフレームワークがお風呂の水で赤ん坊を捨てていると思います---男私は不機嫌そうな悪党プログラマーにならないことを願っています...
Web APIのvalidationアスペクトについて-「モデルの検証」を実行して、400の不正な要求のHTTP応答で応答することが可能です。
前回のアプリケーションでは、REST apiとJavaScriptフロントエンドを組み合わせました。
私がしたことは：
- REST CRUD操作用のAPIを作成しました。
- 定義済みのHTMLテンプレートを読み込み、REST APIから返されたデータを入力するJavascriptアプリケーションを作成しました。
基本的に、JSフロントエンドはREST CRUD操作のAPIと通信し、HTMLに返されたデータまたは作成されたデータを入力するか、削除されたデータを削除するか、変更されたデータを更新します。
したがって、純粋なHTMLがあり、クライアントで処理が行われ、すべてのHTMLをロードする必要がないため、帯域幅の使用が少なくなり、ユーザーに真にWeb 2.0のエクスペリエンスを提供できます。
安全性とコードの重複のためにフロントエンドでビジネス検証を行っていません。サーバーに送信する前に誰でもデータを変更でき、サーバー上のデータを再度検証する必要があるためです。したがって、これは簡単にハッキングされます。すべての検証はバックエンドで行われます。クライアント側の検証は、入力のタイプに対してのみ行われます。
長所：
- JSによって生成されないためにHTMLを変更する機能。
- AjaxとJSONを使用することにより、帯域幅の消費を抑えます。
- HTMLはクライアント側で入力されるため、サーバー処理の消費が少なくなります。
- JSを使用して画面を変更することでユーザーエクスペリエンスが向上し、効果を使用できるようになり、レンダリング速度が向上しました。
- RESTを使用することによる、HTTPプロトコルのより良い使用。
短所：
- 維持する2つのアプリケーション。
- クライアントの処理に依存します。これは、ハードウェアの品質が悪いために悪くなる可能性があります。
お役に立てれば。
よろしく、