私は最近、30以上の異なるページ/機能を含むプロジェクトを終了しました。それぞれにいくつかのCRUDとより多くのサブページがあります。各ページは、目的がまったく異なります。すべては、ASP.NET MVCコアといくつかのAjaxを使用して作成され、いくつかのレンダリングされたビューをクエリしました。
今日、私は複雑さの点でそれに似た新しいプロジェクトを始めています。 Angular4やReactなどのSPAフレームワークから始めたいと思います。ただし、いくつかのオプションがあります。
30の異なるページ/機能とすべてのサブページを含む巨大なSPAを作成し、サーバーサイトをRESTクエリのみに使用します。(巨大なSPA)
通常のMVCサーバーアプリケーションを作成し、AngularまたはReact必要に応じて、いくつかの小さな自己完結型アプリを使用します。スパ)
sPAを忘れてください。
YouTube、Facebook、さらにはStack Exchange(ASP.NET MVCにも組み込まれている)などの人気のあるアプリケーションを見ると、2番目のオプションを使用しているように見えます。各ページは一種のリッチSPAです。設定やプロファイルなどのリンクをクリックすると、サーバーからDOMが読み込まれ、すべてのやり取りはレストフルクエリを使用して行われます。
別の経験豊富なWeb開発者について知りたいのですが。どのオプションが良いですか?
ありがとう
「 単一ページアプリケーションで何が必要ですか? 」などの記事を読んだ後、非常に大きなスパを(遅延読み込みを使用しても)構築することは、大きなシステムのソリューションとしては適切でないと確信していますさまざまな分野で。
1つの大きなSPAが間違っている本当の理由は、カップリングが原因です。アプリケーション全体をSPAとして構築する場合、すべてが結合されます。アプリケーションのあいまいな部分に小さな変更を加えると、グローバルな影響が生じる可能性があります。ページが異なると、偶発的な地球規模の変化の可能性ははるかに小さくなります。これは、コードが実際に別のページに読み込まれた場合にのみ発生します。
そして
実際には、アプリケーションを機能部分に分割することを意味します。ちょっとの間、大規模な販売アプリケーションを構築していると仮定します。次に、おそらく顧客管理を構築する必要があります。記事管理部分もあります。注文入力部分があり、最後にアプリケーションの注文処理部分があります。実際にはもっと多くありますが、例としてこれら4つで十分です。これらの4つはまったく異なり、それぞれに独自の仕事があり、エンドユーザーは仕事を完了するために常にそれらを切り替えることはありません。