誰でもフロントエンド、バックエンド、ミドルウェア(「ミドルエンド」?)の違いを簡潔に比較/対比できるかどうか疑問に思っていました。
それらが重なる場合はありますか?それらが重複しなければならず、フロントエンド/バックエンドを分離できない場合はありますか?ボトルネックに関して、どのタイプのボトルネックにどの端が関連付けられていますか?
内訳は次のとおりです。
フロントエンド層->通常、HTML、Javascript、CSS、Flash、およびASP.Net、従来のASP、PHPなどのさまざまなサーバー側コードの混合で構成されるユーザーインターフェイスレイヤー。これはユーザーに最も近いと考えてください。コードの面で。
ミドルウェア、中間層-> 1層戻り、一般にシステムの「配管」部分と呼ばれます。 JavaとC#は、UIとデータの間の接着剤として見ることができるこの部分を記述するための一般的な言語であり、WebサービスまたはWCFコンポーネントまたは他のSOA =おそらくコンポーネント。
バックエンド層->データベースおよびその他のデータストアは通常、このレベルです。 Oracle、MS-SQL、MySQL、SAP、およびさまざまな既製のソフトウェアが、データの最終処理であるこのソフトウェアのために思い浮かびます。
ビルトインAJAXを使用してASP.Net Webサイトのようにすべてを1つのレイヤーに注ぐことができるため、これらの間にオーバーラップが存在する可能性があります。または、ADOオブジェクトを使用し、3つの層すべてを1つにマージすることにより、VBScriptを使用してすべてのレイヤーとして動作させることもできます。
同様に、場合によっては、ミドルウェアとフロントエンドまたはバックエンドのいずれかを組み合わせることができます。
通常、ボトルネックにはいくつかの異なるレベルがあります。
1)データベースまたはバックエンドの処理->これは、給与や営業、またはデータベースへのスループットが低下している他のタスクとは異なる場合があります。
2)ミドルウェアのボトルネック->これは、一部のWebサービスがキャパシティに達する可能性がありますが、フロントエンドとバックエンドには、より多くのトラフィックを処理するための帯域幅があります。または、BizTalkやMSMQなどを使用してボトルネックになる可能性のあるUI部分や生データではないシステムの一部であるサーバーが存在する場合があります。
3)フロントエンドのボトルネック->これにより、クライアント側またはサーバー側の問題が発生する可能性があります。たとえば、ローエンドPCを使用して、ダウンロードされる大量のデータで構成されるWebページをロードする場合、クライアントはボトルネックのある場所にある可能性があります。同様に、Amazon.comや他のトラフィックの多いWebサイトが時々取得する可能性のあるリクエストでサーバーが攻撃を受けている場合、サーバーはリクエストをキューに入れることができます。
この一部は解釈の対象となるため、いかなる手段およびYMMVによっても完全ではありません。
編集:考慮すべきことは、いくつかのシステムが複数のフロントエンドまたはバックエンドを持つことができるということです。たとえば、コンテンツ管理システムには、サイト訪問者がフロントエンドであるコンテンツを表示する方法がありますが、コンテンツエディターがサイト上のデータを変更する方法はどうでしょうか。このデータをプルする機能は、UIコンポーネントであるためフロントエンドと見なされるか、サイトを表示する一般ユーザーではなく内部ユーザーによって使用されるためバックエンドと見なされる可能性があります。したがって、ここでコンテキストについて言うことがあります。
一般的に、人々はアプリケーションのプレゼンテーション層をフロントエンド、永続層(通常はデータベース)バックエンド、およびその間のすべてを中間層。この一連のアイデアは、しばしば3層アーキテクチャと呼ばれます。これらを使用すると、アプリケーションをより簡単に理解できる(そしてテスト可能!)チャンクに分割できます。また、下位層のコードを上位層でより簡単に再利用できます。
どのコードがどのティアの一部であるかは多少主観的です。グラフィックデザイナーは、プレゼンテーション以外のすべてをバックエンドと考える傾向があり、データベースの人々は、データベースの前にあるすべてをフロントエンドと考えるなどです。
ただし、すべてのアプリケーションをこのように分離する必要はありません。確かにindex.phpを開いてクラッキングを取得するよりも、3つの独立したサブプロジェクトを作成するのは確かに多くの作業です。 (1)アプリを維持する必要がある期間(2)アプリの取得がどれだけ複雑になるかによって、複雑さを控えることができます。
実際、あなたの質問には3つの質問があります:
JB Kingの説明は正しいですが、特定のシンプルなバージョンであり、実際にはフロント、ミドル、およびbacnをMVCレイヤーにマッピングしました。彼はMを後ろに、Vを前に、Cを中央にマッピングしました。
多くの人にとっては、MVCさえも適用されないい世界から来ているので問題ありません。また、ビューで直接DB呼び出しを行うこともできます。
しかし、実際の複雑なWebアプリケーションでは、実際にはフロント、ミドル、バックと呼ばれる2つまたは3つの異なるレイヤーがあります。それぞれに関連するデータベースとコントローラーがあります。
フロントエンドはエンドユーザーに表示されます。フロントオフィスと混同しないでください。フロントオフィスはフロントのパラメーターと管理のためのUIです。フロントエンドは通常、ある種のCMSまたはeコマースプラットフォーム(マゼントなど)です。
ミドルエンドは必須ではなく、ビジネスロジックが存在する場所です。これは、PIM、MDMツール、または製品や記事(CMS用)を充実させる何らかのカスタムデータベースに基づいています。また、異なるフロントエンド間(たとえば、PCフロントエンドとAPIベースのモバイルアプリケーション間)で共有する必要があるビジネス機能をコーディングする場所にもなります。場合によっては、ESBまたはActiveMQなどのツールがミドルエンドになることがあります
バックエンドは、ソースデータベースまたはERPを囲む第3層になります。 APIがERPを読み書きしている可能性があります。電子商取引を行っている場合は、サプライヤDBである可能性があります。実際、Webプロジェクトに本当に依存していますが、常に中央リポジトリです。 DB呼び出し、API、Hibernateレイヤー、またはフル機能のバックエンドアプリケーションのいずれかを介してアクセスされます。
この説明は、このスレッドでは他の2つの質問に答えることができないことを意味します。ボトルネックは実際に3つのエンドに含まれるものに依存するためです。
質問が行われた時点(5年前)では、MVCパターンはまだそれほど広く採用されていなかったのかもしれません。現在、MVCパターンに従わず、ビューがDB呼び出しに結び付けられる理由はまったくありません。 「重複する必要があり、フロントエンド/バックエンドを分離できない場合がある」という質問を読んだ場合より広い意味で、3つの異なるコンポーネントを使用すると、3層アーキテクチャはもちろん役に立たない場合があります。簡単な個人ブログを考えてください。外部データをプルしたり、RabbitMQキューをポーリングしたりする必要はありません。
フロント/ミッド/バックエンドを示す実際の例です。
フロントエンドとバックエンドが重複する可能性があります。これは通常、アプリケーションのメンテナンスとスケーラビリティに関する長期的な問題につながります。レガシーアプリケーションではかなり一般的です。
最新の技術スタックのほとんどは、開発者が厳密に分離することを奨励しています。たとえば、写真では、最初のシステムのバックエンドに、明確な分離線である残りのWebサービスがあることがわかります。
大部分のボトルネックのほとんどは、データベース/ネットワークが原因です。データベースはバックエンドにあります。ネットワークの問題に関しては、すべての接続がnetowrkを経由するため、すべての接続が遅くなる可能性があります。優れたアプリケーション設計により、これらの問題は回避できます。
ネットワークとセキュリティの観点から見ると、バックエンドは間違いなく最も安全なノードです。
通常はWebサーバーであるミドルエンド部分は、やや荒っぽく、多くの点で企業のネットワークから切り離されます。通常、ミドルエンドノードはDMZに配置され、ファイアウォール設定によりネットワークからセグメント化されます。Webページのサーバー側コード解析のほとんどは、ミドルエンドWebサーバーで処理されます。
バックエンドに到達するということは、データベース(バックエンド)サーバーに保存されている重要な数値へのアクセスを許可/禁止する、慎重に作成された一連のルールを持つミドルエンドを経由することを意味します。