ホームページ > バックエンド開発 > PHPチュートリアル > Laravel5.2ブログの実践的なビデオチュートリアルリソースの推奨事項

Laravel5.2ブログの実践的なビデオチュートリアルリソースの推奨事項

黄舟
リリース: 2023-03-15 16:46:01
オリジナル
1691 人が閲覧しました

Laravel は、シンプルでエレガントな PHP Web 開発フレームワーク (PHP Web フレームワーク) です。 ヌードルのような乱雑なコードから解放され、完璧なネットワーク APP を構築するのに役立ち、コードの各行が簡潔で表現力豊かになります。そこで、真の使いこなし入門となるプロジェクト実戦を中心としたLaravel5.2の実践的な開発チュートリアルをまとめた「Laravel5.2ブログ実践ビデオチュートリアル」を集めました。皆さんが Laravel フレームワークをより良く学ぶのに役立つことを願っています。

Laravel5.2ブログの実践的なビデオチュートリアルリソースの推奨事項

コース再生アドレス: http://www.php.cn/course/283.html

先生の指導スタイル:

講義はフレンドリーで自然で、気取らず、気取らないものです。意図的に誇張するのではなく、雄弁かつ詳細に話し、教師と生徒は平等、協力、調和の雰囲気の中で静かに感情的な交流を行い、知識の渇望と探求をシンプルさと信頼性の中に統合します。 教育現場では、生徒は知識を獲得します。静かに考え、静かに承認します

このビデオのさらに難しい点は、HTTP ミドルウェアです:

-- ミドルウェアとは何ですか?
1. ミドルウェアが必要な理由

コンピューター技術は急速に発展しています。ハードウェア技術の観点から見ると、CPU の速度はますます高速になり、ソフトウェア技術の観点からは、アプリケーション プログラムの規模はますます増大しており、特にインターネットや WWW の出現が顕著です。これにより、コンピュータの適用範囲が広がり、多くのアプリケーションが作成されます。プログラムは、ネットワーク環境の異種プラットフォーム上で実行する必要があります。これらすべてが、新世代のソフトウェア開発に対する新たな要求を提起します。この分散型異種環境では、通常、複数のハードウェア システム プラットフォーム (PC、ワークステーション、ミニコンピュータなど) が存在し、これらのハードウェア プラットフォーム上にはさまざまなシステム ソフトウェア (さまざまなオペレーティング システム、データベースなど) が存在します。これらのハードウェア システム プラットフォームは、接続に異なるネットワーク プロトコルやネットワーク アーキテクチャを使用する場合もあります。これらのシステムをどのように統合して新しいアプリケーションを開発するかは、非常に現実的で難しい問題です。

II ミドルウェアとは

分散型異質性の問題を解決するために、人々はミドルウェアの概念を提案しました。ミドルウェアは、図 1 に示すように、プラットフォーム (ハードウェアおよびオペレーティング システム) とアプリケーションの間に位置する共通のサービスです。これらのサービスには、標準のプログラム インターフェイスとプロトコルがあります。オペレーティング システムやハードウェア プラットフォームが異なる場合、インターフェイスやプロトコルの仕様に準拠した複数の実装を行うことができます。

ミドルウェアの厳密な定義を与えることは難しいかもしれませんが、ミドルウェアは次の特性を持つ必要があります:

多数のアプリケーションのニーズを満たす
さまざまなハードウェアおよび OS プラットフォーム上で実行する
分散コンピューティングをサポートし、相互接続を提供するネットワーク、ハードウェア、OS プラットフォームの透過性を備えたアプリケーションまたはサービスの相互作用
標準プロトコルのサポート
標準インターフェイスのサポート

移植性のための標準インターフェイスと相互運用性のための標準プロトコルの重要性により、ミドルウェアは多くの標準化の取り組みの主要部分となっています。アプリケーション ソフトウェア開発では、ミドルウェアが提供するプログラム インターフェイスは、基盤となるコンピュータ ハードウェアとシステム ソフトウェアがどのように更新されても、比較的安定した高レベルのアプリケーション環境を定義します。ミドルウェアはアップグレードおよび更新され、ミドルウェアの外部インターフェイス定義は変更されずに維持されます。アプリケーション ソフトウェアはほとんど変更を必要としないため、アプリケーション ソフトウェアの開発とメンテナンスに対する企業の多大な投資が保護されます。

3. 主要なミドルウェアの分類

ミドルウェアは非常に広範囲をカバーしており、アプリケーションのニーズに応じてさまざまな特徴的なミドルウェア製品が登場しています。しかし今のところ、ミドルウェアのより正確な定義は存在しないため、ミドルウェアの分類はさまざまな観点やレベルによって異なります。ミドルウェアは分散環境で異種のオペレーティング システムとネットワーク プロトコルを保護する必要があるため、分散環境で通信サービスを提供できなければなりません。この通信サービスをプラットフォームと呼びます。さまざまな目的と実装メカニズムに基づいて、プラットフォームを次の主要カテゴリに分類します:

リモート プロシージャ コール
メッセージ指向ミドルウェア
オブジェクト リクエスト ブローカー

同期、キューイング、サブスクリプションなど、さまざまな形式の通信サービスを上向きに提供できます。これらの基本的な通信プラットフォームの上に、トランザクション処理モニター、分散データ アクセス、オブジェクト トランザクション マネージャー OTM など、さまざまな分野のサービスをアプリケーションに提供するためのさまざまなフレームワークを構築できます。プラットフォームは、上位層アプリケーションの異種プラットフォーム間の差異を保護し、その上のフレームワークは、対応する分野のアプリケーションのシステム構造、標準サービスコンポーネントなどを定義します。ユーザーは、フレームワークに関心のあるイベントを伝えるだけで済みます。 、これらのイベントの処理を提供します。イベントが発生すると、フレームワークはユーザーのコードを呼び出します。ユーザー コードはフレームワークを呼び出す必要はなく、ユーザー プログラムはフレームワークの構造、実行プロセス、システム レベル API の呼び出しなどを気にする必要がなく、これらはすべてフレームワークによって完了されます。したがって、ミドルウェアに基づいて開発されたアプリケーションは、優れた拡張性、容易な管理、高い可用性、移植性を備えています。

以下は、いくつかの主要なタイプのミドルウェアの簡単な紹介です。

1. リモート プロシージャ コール

リモート プロシージャ コールは、広く使用されている分散アプリケーション処理方法です。アプリケーションは RPC を使用して、別のアドレス空間にあるプロセスを「リモート」で実行し、ローカル呼び出しを実行するのと同じ効果があります。実際、RPC アプリケーションはサーバーとクライアントの 2 つの部分に分かれています。サーバーは 1 つ以上のリモート プロシージャを提供し、クライアントはサーバーに対してリモート呼び出しを行います。サーバーとクライアントは、同じコンピュータ上に配置することも、異なるコンピュータ上に配置することも、異なるオペレーティング システム上で実行することもできます。彼らはネットワークを通じて通信します。対応するスタブとランタイム サポートはデータ変換と通信サービスを提供し、それによってさまざまなオペレーティング システムとネットワーク プロトコルを保護します。ここでの RPC 通信は同期です。スレッドを使用して非同期呼び出しを行うことができます。

RPC モデルでは、クライアントとサーバーが対応する RPC インターフェイスを持ち、RPC 実行サポートを備えている限り、特定のサーバーに限定されることなく、対応する相互運用を完了できます。したがって、RPC はクライアント/サーバー分散コンピューティングを強力にサポートします。同時に、リモート プロシージャ コール RPC はプロセス ベースのサービス アクセスを提供し、クライアントとサーバーは直接接続されており、リクエストを処理する仲介機関がないため、一定の制限もあります。たとえば、RPC では通常、サーバーを見つけるためにネットワークの詳細が必要です。クライアントがリクエストを行うときは、サーバーがアクティブである必要があります。

2. メッセージ指向ミドルウェア

MOM は、プラットフォームに依存しないデータ交換のための効率的で信頼性の高いメッセージ パッシング メカニズムの使用と、データ通信に基づく分散システムの統合を指します。メッセージ パッシング モデルとメッセージ キューイング モデルを提供することにより、分散環境でのプロセス間通信を拡張し、複数の通信プロトコル、言語、アプリケーション、ハードウェアおよびソフトウェア プラットフォームをサポートします。現在人気のある MOM ミドルウェア製品には、IBM の MQSeries、BEA の MessageQ などが含まれます。メッセージ パッシングおよびキューイング テクノロジには、次の 3 つの主な機能があります:

通信プログラムは異なる時間に実行できます。プログラムはネットワーク上で直接通信しませんが、直接的な接続がないため、間接的にメッセージをメッセージ キューに入れます。プログラムの間。したがって、同時に実行する必要はありません。メッセージが適切なキューに配置されるとき、ターゲット プログラムが実行されている必要はありません。ターゲット プログラムが実行されている場合でも、メッセージをすぐに処理するわけではありません。

アプリケーション プログラムの構造に制約はありません。複雑なアプリケーション シナリオでは、通信プログラムは 1 対 1 の関係だけでなく、1 対多および多対 1 のメソッド、あるいはそれらの組み合わせも持つことができます。上記の方法。複数の通信方式を構築しても、アプリケーションの複雑さは増加しません。

プログラムはネットワークの複雑さから隔離されています

プログラムは、通信のためにメッセージキューにメッセージを入れるか、メッセージキューからメッセージを取り出します。また、これに関連するすべてのアクティビティ(メッセージキューの維持、プログラム間の関係の維持など)も行います。ネットワークの再起動の処理とネットワーク上でのメッセージの移動は MOM のタスクであり、プログラムは他のプログラムと直接通信せず、複雑なネットワーク通信を必要としません。

3. オブジェクト リクエスト エージェント

オブジェクト テクノロジーと分散コンピューティング テクノロジーの発展により、この 2 つが結合して分散オブジェクト コンピューティングが形成され、今日のソフトウェア テクノロジーの主流の方向に発展しました。 1990 年末に、オブジェクト管理グループ OMG は、このモデルの中心となるコンポーネントであるオブジェクト管理アーキテクチャ OMA (オブジェクト管理アーキテクチャ) を初めて立ち上げました。その役割は、異種分散コンピューティング環境でオブジェクト要求を透過的に配信するための通信フレームワークを提供することです。 CORBA 仕様には、ORB のすべての標準インターフェイスが含まれています。 1991 年に発表された CORBA 1.1 では、インターフェイス記述言語 OMG IDL と、クライアント/サーバー オブジェクトが特定の ORB 上で相互運用できるようにサポートする API が定義されました。 CORBA 2.0 仕様では、異なるベンダーが提供する ORB 間の相互運用性について説明しています。

オブジェクト リクエスト ブローカー (ORB) は、CORBA 仕様の中核となるオブジェクト バスであり、異種環境でオブジェクトが透過的にリクエストを送信し、レスポンスを受信するための基本メカニズムを定義します。これは、クライアント/サーバーを確立するミドルウェアです。オブジェクト間の関係。 ORB を使用すると、オブジェクトが他のオブジェクトに透過的にリクエストを送信したり、ローカルまたはリモート マシン上にある他のオブジェクトから応答を受信したりできます。 ORB はリクエストの呼び出しをインターセプトし、リクエストを実装できるオブジェクトの検索、パラメータの送信、対応するメソッドの呼び出し、結果の返しなどを行います。クライアント オブジェクトは、サーバー オブジェクトとの通信、サーバー オブジェクトのアクティブ化または保存のメカニズムを知りません。また、サーバー オブジェクトがどこにあるか、どの言語で実装されているか、どのオペレーティング システムが使用されているかなどを知る必要もありません。オブジェクト インターフェイスの一部ではないシステム コンポーネント。

クライアント ロールとサーバー ロールは、対応する状況に応じて、オブジェクト間の対話を調整するためにのみ使用されることを指摘しておく価値があります。ORB 上のオブジェクトは、クライアント、サーバー、またはその両方になる可能性があります。オブジェクトがリクエストを行うときはクライアント ロールになり、リクエストを受信するときはサーバー ロールになります。ほとんどのオブジェクトはクライアントとサーバーの両方の役割を果たします。さらに、ORB はオブジェクト要求の送信とサーバー管理を担当するため、クライアントとサーバーの間に直接的な接続はありません。そのため、RPC でサポートされる単純なクライアント/サーバー構造と比較して、ORB はより複雑な構造をサポートできます。

4. トランザクション処理モニタリング

トランザクション処理モニタはメインフレームに初めて登場し、大規模なトランザクション処理をサポートする信頼性の高い動作環境を提供します。分散コンピューティング技術の発展に伴い、分散アプリケーション システムでは、商業活動における多数の重要なトランザクション処理など、大規模なトランザクション処理の要求が高まっています。トランザクション処理監視はクライアントとサーバー間で行われ、トランザクションの管理と調整、負荷分散、障害回復などを実行して、システム全体のパフォーマンスを向上させます。これは、トランザクション処理アプリケーションの「オペレーティング システム」と考えることができます。一般的に、トランザクション処理監視には次の機能があります:

サーバープロセスの起動、タスクの割り当て、実行の監視、負荷の分散などのプロセス管理。
トランザクション管理は、その監視の下でトランザクション処理の原子性、一貫性、独立性、耐久性を保証します。
通信管理は、リクエスト応答、セッション、キューイング、サブスクリプションの公開とブロードキャストなどを含む、クライアントとサーバー間のさまざまな通信メカニズムを提供します。
トランザクション処理モニタリングは、飛行機の発券システムなど、多数のクライアントにサービスを提供できます。サーバーが必要なリソースを各クライアントに割り当てると、サーバーに負荷がかかります (図 2 を参照)。しかし実際には、すべてのクライアントが同時にサービスを要求する必要があるわけではなく、クライアントがサービスを要求すると、すぐに応答が得られることを望んでいます。トランザクション処理監視は、オペレーティング システム上で一連のサービスを提供し、クライアントのリクエストを管理し、対応するサービス プロセスをそれらに割り当てます。これにより、サーバーは限られたシステム リソースで大規模な顧客にサービスを効率的に提供できます。

以上がLaravel5.2ブログの実践的なビデオチュートリアルリソースの推奨事項の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート