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でほぼすべてを構築するかを選択する方法です。

これがクライアント側の開発者にとって望ましい理由は、誰もデータベースにHTMLを必要としない理由とほとんど同じです。たとえば、HTMLを渡されたときにテーブルを再利用したい場合、クライアント側の開発者は何をすべきでしょうか？クライアント上ですべてを処理するパフォーマンスコストは、別のサーバーリクエストを実行してユーザーに代わって実行する場合と比べると簡単です。また、HTML構築はJSランドでかなりよくカバーされています。経験豊富なクライアントサイド開発者にとって、データのソートとそこからの新しいHTMLテーブル行の構築は非常に簡単な作業です。

また、100％キャンバスまたはまったく異なるHTML構造のウィジェットを実装するなど、エキゾチックな何かをする必要があるかもしれない別のデバイスのフロントエンドに対するバックエンドアーキテクチャはどのような用途ですか？クライアント側の開発者がビジュアルスタジオをロードするか、バックエンドの開発者のドアをノックして、厳密にプレゼンテーションを微調整する必要があるのはなぜですか？

厳密に型指定されたテンプレート検証の損失についての懸念については、有能なクライアントサイド開発者を扱っている場合、。ダイヤモンドから粉塵への道のりで、彼よりも整形式で有効なHTMLについてアナルです。

フルスタックの観点からは、Yutzがテンプレートレイヤーにドロップすることを決めたビジネスロジックやアプリロジックのために釣りをする必要がないことを意味するので、気に入っています。多くの場合、最新のコンピューターを搭載した最新のブラウザーでユーザーの負荷エクスペリエンスを実際に向上させながら、サーバーごとにユーザーごとの負荷がかかることは言うまでもありません。

また、バックエンドアーキテクチャをすべてのプレゼンテーションから完全に分離した場合、バックエンドアーキテクチャについて推論するのも簡単だと思います。データを取得してHTMLにマッシュする必要はもうありません。それをまとめて、実装に依存しないデータ構造を作成します。これは、反対側で行われることよりも一般的な使用に関係します。IMOは、データがプロセスの最後から2番目のステップではなく最終目標であり、関係のない懸念がワイヤを渡る機会が少ないため、物事の処理方法の一貫性を高める傾向があります。

私は非常に主観的な2ペニーの価値を提供します（価値があるもののために;））。これには正しい答えも間違った答えもありません。あなたのポイントに加えて、多くの現実世界の考慮事項があります。例えば：

• 社内で関連する経験はありますか？クライアント側駆動型アプリの構築は、完全に異なるスキルセットを持つ主にサーバー駆動型アプリとは大きく異なります。
• どのくらい時間がかかり、どのブラウザをサポートする必要がありますか？-クライアントで行う操作が増えるほど、直面するブラウザの問題が増えます。IE8は痛みを伴い、JavaScriptのパフォーマンスは非常に劣りますが、XP / IEのセットアップを実行している企業はたくさんあります。
• ユーザーがどのデバイスでサイトを表示しますか？JavaScriptの解析と実行は、Chromeの最近のバージョンでは高速になる可能性がありますが、古いモバイルデバイスでは動作しません。特に、ビジネスロジックがロードされている大量のJavaScriptでは動作しません
• 初期ロードはどのくらい重要ですか？サーバーのテンプレートはクライアントのテンプレートよりも高速です

このリストは決して網羅的なものではなく、クライアント側のバッシングのように聞こえますが、これは私の意図ではありません。フロントエンドを重視したサイトを作成しました。

私にとっては、ユーザーエクスペリエンスとAPIの再利用性にかかっています。これらのそれぞれに対処します。

アプリを作成する場合やAPIを提供する場合、.Net APIプロジェクトを使用することには多くの意味があります。これにより、ロジックが形成され、プラットフォームを越えてチェックおよび実装されます。このシナリオでは、完全なクライアント側アプローチが好ましい場合があります。APIは個別に維持でき、アプリケーションへのインターフェイスを提供するだけです。ロジックを修正してリファクタリングを快適に行うことができ、インターフェースを同じに保つ必要があります。同じバックグラウンドコードを使用して、すべてのメディアに異なるアプリケーションを簡単に作成できます。

（私の意見では）純粋なフロントエンドソリューションの最も強力な議論は、ユーザーエクスペリエンスです。

（すべての欠点を考慮すると）純粋なJavaScriptブラウザーアプリケーションは、従来のWebサイトでの使いやすさとユーザーエクスペリエンスを大幅に改善しますか？

ネイティブアプリケーションのように機能するサイトを作成する場合。私はその答えは明らかなイエスだと主張します。ただし、ほとんどのサイトはこのように完全にはカットされていないため、個々のユーザーワークフローが非常に動的なインターフェイスの恩恵を受けるかどうかを評価する必要があります。

私はこれについてかなり実用的な見方をしているが、どちらでも問題でもない。JavaScriptは明らかにサーバーテクノロジーと一緒に非常に楽しく再生され、いずれかを選択する必要はありません-すべてのサイトが単一ページのWebアプリではありません-しかし、個々のページでKnockout、バックボーンなどを使用するのを止めるものは何もありません必要だと思われる箇所を改善します。

私は、フロントエンドの重いアプリケーションと愛憎関係を持っています。

一方では、JavaScriptを書くのが大好きで、実行環境としてのブラウザーが大好きです。

一方、両方ともエンジンに穴のあるフォーミュラ1レースカーのように感じます。つまり、C＃とJavaScriptの間のビジネスロジックの重複を防ぐことができますか？もしそうなら、あなたがふさわしいと思うビューを生成するためにどんな方法を使ってください。2つの言語でビジネスロジックを複製している場合、JavaScriptを記述したいだけで、全体像をあまり見ないフロントエンドの開発者がいるかもしれません。

技術的な違いに関して：

パーシャルのレンダリングとクライアントへの配信：

• 簡単で迅速な実装
• バックエンドのビジネスロジックがフロントエンドで複製されるのを防ぎます
• ブラウザーへのHTTPペイロードがはるかに大きくなる可能性があります。高帯域幅接続を備えたデスクトップでは、悪いことではありません。ラッシュアワーの電車に乗っていて、時速60マイルで線路を急いでいるとき、他の1,000台の携帯電話が1つのセルタワーから同時に切断され、次のセルタワーに再接続しようとしています。

JSONの配信とクライアント側テンプレートのレンダリング：

• 結果として、HTMLよりも小さいHTTPペイロードが発生する可能性があります。これにより、信頼性の低いネットワーク接続や低速なネットワーク接続でのアプリケーションの応答性が向上します。
• 多くのJavaScriptテンプレート言語は完全に機能しているため、HTMLを生成するためだけにバックエンドは不要です。

時々、新しいJavaScriptフレームワークがお風呂の水で赤ちゃんを追い出していると思います---私は不機嫌なプログラマーのプログラマーにならないことを望みます...

前回のアプリケーションでは、REST APIとJavaScriptフロントエンドを組み合わせました。

私がしたことは：

• CRUD操作用のREST APIを作成しました。
• 事前定義されたHTMLテンプレートをロードし、REST APIから返されたデータを取り込むJavascriptアプリケーションを作成しました。

基本的に、JSフロントエンドはCRUD操作のためにREST APIと通信し、返されたデータまたは作成されたデータをHTMLに追加するか、削除されたデータを削除するか、変更されたデータを更新します。

したがって、純粋なHTMLがあり、クライアントで処理が行われ、すべてのHTMLをロードする必要がないため帯域幅の使用量が少なくなり、ユーザーにWeb 2.0を真に体験できます。

誰でもデータをサーバーに送信する前に変更でき、サーバー上のデータを再度検証する必要があるため、フロントエンドで安全性とコードの複製のためにビジネス検証を行いません。したがって、これは簡単にハッキングされます。すべての検証はバックエンドで行われます。クライアント側の検証は、入力の種類に対してのみ行われます。

長所：

• JSによって生成されないため、HTMLを変更する機能。
• ajaxとJSONを使用して帯域幅の消費を抑えます。
• HTMLはクライアント側に入力されるため、サーバー処理の消費が少なくなります。
• JSを使用して画面を変更し、エフェクトを使用してレンダリング速度を上げることにより、ユーザーエクスペリエンスが向上しました。
• RESTを使用することによる、HTTPプロトコルのより良い使用。

短所：

• 維持する2つのアプリケーション。
• クライアントの処理に依存しますが、これはハードウェアの品質が悪いために悪い場合があります。

お役に立てれば。

よろしく、

validationWeb Api の側面について-「モデルの検証」を実行し、400の不良リクエストhttp応答で応答することが可能です。

参照/programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285