Web ブログに PHP mvc フレームワーク (Codeigniter) を使用しています。
私は初めて Ajax を実装して、実際のメリットを自分で確認します。
HTML ページでの書式設定や結果の表示など、ビューから行ったことは、Ajax 実装に置き換えることができると思います。したがって、サーバー側の mvc のビューは使用されなくなると思います。
フォームの検証では、javascript がバイパスされた場合に備えて、クライアントとサーバーの両方のロジックを装備することをお勧めします。クライアントブラウザからjavascriptが無効になっている場合、ここでは同じ概念がAjaxに適用されると思います。つまり、無効にするとデータを取得できません。検証の処理方法など、このシナリオのバックアップ ソリューションは何でしょうか?
あなたは 2 つの質問をしましたが、私は最初の質問に答えます。AJAX は、従来のサーバー側のビューの役割を置き換えることができますか?
MVC Web フレームワークでは、ビューはコントローラーから渡されたデータを HTML に変換するためのテンプレートですが、クライアント側のテンプレート言語は非常に人気があり、サーバーで HTML 出力をレンダリングするための完全に合理的な代替手段であり、明確な利点があります。 .
まず、HTML ペイロード全体をクライアント ブラウザーに送信するのではなく、コンテンツのみを送信するため、帯域幅を大幅に節約できます。HTML クライアント側を生成すると、データ (JSON や XML など) のみをクライアントに送信できます。サーバー側のビューには、JavaScript テンプレートとコンテンツ ペイロードを指すスクリプト タグが含まれているだけです。
第 2 に、これらの JavaScript テンプレートは CDN から提供できるため、これらのネットワークの速度とページ間のキャッシュの恩恵を受けることができるため、ユーザーは特定のページに固有のテンプレートとデータのみをダウンロードする可能性があります。
ただし、いくつかの回避策はありますが、SEO などのいくつかの欠点があります。1 つのオプションとして、サーバー サイド ビューを使用してページの SEO フレンドリー バージョンをクローラーに提供するか、Node.js または Rhino を使用してテンプレートをサーバー サイドで単純にレンダリングします。JavaScript にコンパイルされた言語でテンプレートを作成することの利点は、サーバーとブラウザーの両方でテンプレートを実行できることです。これは、他のどの言語でも言えることではありません。