なぜ単一ページのアプリケーションが必要なのですか？
Single Page Application （SPA）がやってきました。ルーティング、クライアントサイドのページライフサイクル、MVCパターン、MVVMパターン、MV *パターンなど、多くの新しいものも付属しています。Javascriptパターンの一部も次のようになります AMDパターン 、 シングルトン 、 ファサード 、..
多くのSPAフレームワークとライブラリも開発されました。そのいくつかをインターネットで見つけることができます。それらは AngularJs 、 Reactjs 、 BackboneJs 、 DurandalJs 、および.. RequireJs 、 Amplifyjs 、 BreezeJs ...のようなより簡単なJavascriptコーディング.
しかし、なぜSPAが必要なのでしょうか？ Webアプリケーションの開発において、いくつかの新しい複雑なことを導入しているように見えるからです。 SPAにもかかわらず、従来のWebアプリケーションを使用して、各読み込みページをリクエストできます。モバイルで簡単に実行でき、新しいWebアプリケーション開発トレンドに適応できるというメリットがあります。誰かがそれについてより明確に説明できますか？
もう1つ、多くのサードパーティコンポーネントを使用して1つのSPAのみを構成する場合。それでは、このWebアプリケーションの一貫性が保たれますか？私たちのウェブアプリケーション内で巨大なコンポーネントを維持するための複雑なものになると思います。それについてどう思いますか？
すべての提案を歓迎します。
これは、ユーザーが現在使用しているデバイスの数と、それぞれの機能と制限を考慮して、ほとんどのWebサイトがこれに向かって進むべき方向だと思います。
重要：
これ以降を読む前に、この概念はWeb向けの設計の基本原則に基づいて構築されていることを理解してください。すべてのデバイスと状況に対応する単一ページアプリケーションを設計するために、単一ページアプリケーションとして排他的に実行することはできません。高度に制限された機能を備え、デバイスの機能に応じてユーザーエクスペリエンスを向上させる最も基本的なブラウザーで動作する基盤を構築する必要があります。
これはあなたのためにより多くの仕事を引き起こすかもしれませんが、あなたはより多くのより多様な聴衆を満足させることができます。これは現代のデスクトップまたは電話ブラウザ専用具体的には.
ロード時間および/または重量を減らす
シングルページアプリケーションは、ページの読み込み時間とサーバーからクライアントへのデータ転送量を減らすことができます。
このメソッドの最も大きな影響を与える機能には次のものがあります。
- 初めてロードされたグローバル機能を保存する、
- ページ間のデータ転送をより簡単にし、より複雑なユーザーインターフェイスを実現する
- 特定のコンポーネントのみが必要な場合、ポストバック後にページ全体をロードするコストを削除します
複雑すぎる可能性の増加
この設計方法は、開発者の怠とエンドユーザーからのより多くの干渉を可能にする可能性があります。開発者として、UIが仕事をすることを確認してください（取得、表示、送信サーバーへ）、サーバーがその仕事をすること（データベースへの提供、検証、送信）。ほとんどのエンドユーザーは、javascriptファイルの情報を使用してシステムを破壊しようとはしませんが、データ構造に関する情報を含めることは、私の意見ではトラブルを求めています。
強力なアーキテクチャから始めましょう！
他のWebページと同様に、データの処理はページの代わりにサービスハンドラーに直接移動できます。これにより、次のレイヤーを使用するアーキテクチャが可能になります。
- データベース（データストレージ）
- BL（データ処理と転送）
- ユーザーインターフェイス（データ表示とユーザーインタラクション）
ページ処理を介したサービス
私の意見では、サービスを使用することは、Webサイトでの組織化および変調されたコードの要件です。下位互換性のあるWebサイトで使用される標準のgetおよびpostメソッドは、これらのサービスを使用して、ページではなくビジネスオブジェクトを表すサービスにアクセスすることもできます。これにより、同じオブジェクトに関するモジュール間でコードをより一般化できます。
単一ページアプリケーションの更新は、UIを初期化してgetメソッドまたはpostメソッドを取得し、イベントのポストバックを発生させる代わりにAJAXメソッドを使用してそれらを実行できるため、単純化されます。単一ページのインスタンス。
これらのサービスを使用してUIイベントを処理することの副作用は、ライフサイクルイベントを除き、コードビハインドファイルでイベント処理の必要性がなくなることです。ライフサイクルイベントは、関連するデータを処理および変更して状況に基づいて表示したり、返されたhtmlを変更してユーザーのデバイスの負荷を軽減したりするのに役立ちます。
遅延読み込み！
複雑なWebサイトには、複雑なモジュールと独自のコンポーネントが多数含まれます。
単一ページのアプリケーションを使用することで得られる利点は、Ajaxプロセスにロード時間を延期するオプションがあり、アプリケーションの任意の部分が好きなときにそうすることです（つまり、モジュールを最初に使用する試み、ページの読み込みなど）、初期読み込みを高速化し、処理時間をより制御します。
ベストプラクティスのリスト
ベストプラクティスについては、かなり少数のような最適化があり、この方法を使用することを意図した設計に対して行うことができます。
- 情報をそのまま保存し、関連性がなくなった時点で消去する
- 必要な場合にのみ、ajaxを介してスクリプト、html、jsファイルを読み込む
- 新しい「ページ」ごとにリロードする代わりに、あるページにロードされたデータを別のページに使用する
- uIの最小限のデータ構造。表示するための手段であり、処理するためではありません。
- uIでの検証に取り付かないでください。サービスは、送信された情報を検証するために既に構築されている必要があるためです。
これらの最適化は、ロード時間、データ処理、オブジェクトの関連付けに役立ちます。明らかにこれは完全なリストではありませんが、単一ページのアプリケーションを構築するための素晴らしい出発点です。
最後に、1つのWebの設計の概念を調査して、強固な基盤を構築することをお勧めします。その後、残りは比較的単純な拡張機能です。 （ヒント：これらの拡張機能の1つは、ポストバックをもたらすすべてのアクションをキャッチし、その情報を使用して代わりに非同期呼び出しを作成することです）。
これに関するあらゆる種類の情報、および使用するあらゆる種類のライブラリ、がありますが、基本機能および/に可能な限り独自のコードを使用することをお勧めしますあなたの問題を解決するライブラリコードに入り、いくつかの研究を行う汎用ライブラリコードで複雑なシステムを実装しようとする代わりに。コードを例として使用すると、特定の状況でオーバーヘッドが小さくなり、コードが強力になる可能性があります。
がんばろう！