laravel4.2に基づく関連アーキテクチャ設計、laravel4.2アーキテクチャ設計_PHPチュートリアル

laravel4.2関連のアーキテクチャ設計に基づいて、laravel4.2アーキテクチャ設計

プロジェクトチームは少し前にlaravelフレームワークを導入し、私はlaravelのリサーチとプロジェクトアーキテクチャ設計に参加しました。私は個人的に、プロジェクト アーキテクチャの Laravel に基づいたいくつかの設計が非常に実用的で参考になると考えています。学び、議論したいと考えて、いくつかの設計を共有します。特に、この記事は、lavarel の公式ドキュメントの抜粋または要約ではありません。

1例外処理

1.1 例外クラス

例外クラスは app/lib/Exception の下に配置され、ビジネス モジュールに従って細分化できます。

のように、短縮された例外クラスは 1 つのファイル内に複数の例外クラスの形式で存在します。

クラス HttpRequestException は Exception を拡張します

{

}

クラス HttpResponseException は Exception を拡張します

{

}

1.2 キャプチャメカニズム

例外のキャッチは、必要に応じてどこでも行うことができます。キャッチされなかった場合、例外は最外層にスローされます。

最外層にスローされた例外の場合、ハンドラーは app/start/global.php ファイルで定義されます

関数 handleException($code, $Exception)

{

return Decorate::failed($code, null, $例外->getFile() . ':' . $例外->getLine() . ',' . $例外->getMessage());

}

App::error(function(HttpRequestException $例外, $code)

{

return handleException(-1007, $Exception);

});

App::error(function(HttpResponseException $例外, $code)

{

return handleException(-1008, $Exception);

});

1.3 投げる仕組み

例外は、例外をトリガーできる場所ならどこでもスローできます。

RequestLog::r​​equest($url, $data, $start, $content);

if (!$content) {

新しい HttpRequestException($url . ':' . $data) をスローします;

}

2 ロギング

ログにはインターフェース呼び出しログ(RequestLog)、ビジネスログ(LogicaltLog)、デバッグログ(DebugLog)の3種類があります。ログは app/lib/log ディレクトリに配置されます。このうち、RequestLog はインターフェイス呼び出しの統計分析に使用でき、LogicaltLog は論理データの記録に使用でき、DebugLog はデバッグ情報の出力に使用できます (laravel に付属の Log クラスを直接使用することもできます)。

3タスクキュー

Laravle はタスクキューとして使用する Queue をカプセル化しており、非同期処理に非常に便利です。サポート: 「sync」、「beanstalkd」、「sqs」、「iron」、「redis」の 5 つの形式。非常に使いやすいので、redis の使用をお勧めします。

キューを利用するには、タスククラスのクラス名をキューにプッシュするだけで、タスククラスがfireメソッドを実装して利用できるようになります。

fire($job, $data) では、タスクの試行回数 $job->attempts() を取得することもでき、タスクの応答時間を遅らせることもできます $job->release(30);タスクを削除 $job->delete();

最後に、laravel フレームワークの職人ツールを通じてキュー監視を開始できることを特別に思い出させてください:

php ../../../../artisan --env=devqueue:listen&

4 フィルター

フィルターはパラメータ検証、ログインステータスチェック、インターフェース呼び出しログに使用できます。

4.1 パラメータチェック

app/config/param.phpに各インターフェースのパラメータ検証条件を定義します。検証条件についてはlaravelのドキュメントを参照してください。

次に、app/Filter.php の前で、次のような各呼び出しのパラメータ検証を実行します。

App::before(function($request))

{

…

$res = Param::verification(Input::all(), $standard);

…

}

4.2 インターフェース呼び出しログ

App::after(function($request, $response)

{

…

RequestLog::log($request, $response);

…

});

5つの環境切り替え

通常、私たちのフレームワークにはいくつかの環境セットがあります: 正式、テスト、ローカル、サンドボックスなど。環境構成が異なれば、間違いなく異なります。 Laravel では、プロセスの開始時に現在の構成環境を指定できるため、異なる環境間で自動的に切り替えることができます。

1) 異なる環境構成ディレクトリ:

appconfigdev

アプリ構成公式

appconfiglocal

2) bootstrap/start.php は、テスト環境 dev などの必要な環境を指定します

$env = $app->detectEnvironment(‘dev’)

3) 自動的に切り替える方法は?

インターフェースリクエストによってアクセスされるさまざまなドメイン名に基づいて、対応する環境を指定できます。たとえば、dev.domain.com はテスト環境であり、domain.com は公式環境です。

ソフトウェアシステムアーキテクチャ設計とは

ソフトウェア アーキテクチャは、大規模なソフトウェア システムのあらゆる側面の設計をガイドするために使用される、関連する一連の抽象パターンです。 ソフトウェア アーキテクチャはシステムのスケッチです。ソフトウェア アーキテクチャによって記述されるオブジェクトは、システムを直接構成する抽象的なコンポーネントです。コンポーネント間の接続は、コンポーネント間の通信を明確かつ比較的詳細に説明します。実装フェーズでは、これらの抽象コンポーネントは、特定のクラスやオブジェクトなどの実際のコンポーネントに洗練されます。オブジェクト指向の分野では、コンポーネント間の接続は通常、インターフェイス (コンピューター サイエンス) を使用して実装されます。
ソフトウェアアーキテクチャは、コンピュータソフトウェアの実践を構築するための基礎です。建築家が製図者の図面の基礎として建築プロジェクトの設計原則と目標を設定するのと同じように、ソフトウェア アーキテクトまたはシステム アーキテクトは、さまざまな顧客のニーズを満たす実際のシステム設計ソリューションの基礎としてソフトウェア アーキテクチャを述べます。
ソフトウェアアーキテクチャは、ほとんどのエンジニア（特に経験の浅い人）は直感的に理解できる概念ですが、正確に定義するのは困難です。特に、デザインとアーキテクチャを明確に区別することは困難です。アーキテクチャは、特定の特定の機能に焦点を当てたデザインの側面です。
『ソフトウェア アーキテクチャ入門』の中で、David Garlan と Mary Shaw
は、ソフトウェア アーキテクチャは次の問題に関連する設計レベルであると考えています。新たな問題には、全体的な組織構造とグローバルな制御構造、設計要素の物理的な配置、および代替設計の選択が含まれます。しかし、アーキテクチャは単なる構造ではありません。アーキテクチャに関する定義には、システムの完全性、経済的制約、美的要件への「準拠」も含まれます。内部的な考慮事項だけでなく、システムのユーザー環境と開発環境におけるシステムの全体的な考慮事項、つまり外部の考慮事項にも同時に注意を払う
Rational Unified Process では、ソフトウェア システムのアーキテクチャ (時点)特定のポイント) は、インターフェイスを介して相互作用するシステムの重要なコンポーネントの組織や構造、およびインターフェイスで構成されるコンポーネントを指します。ソフトウェアアーキテクトは、ソフトウェアのモジュール化、モジュール間の相互作用を定義および設計するために、ソフトウェア理論に関する広範な知識とそれに対応する経験を持っている必要があります。ユーザー インターフェイス、外部インターフェイス メソッド、革新的な設計機能、およびオブジェクトの操作、ロジック、および上位レベルのプロセス。
システムは通常、コンポーネントで構成されており、これらのコンポーネントがどのように形成され、どのように相互作用するかがシステム自体の構造に関する重要な情報になります
詳細には、アーキテクチャコンポーネントが含まれます。 (アーキテクチャコンポーネント)、コネクタ、およびタスクフロー。
いわゆるアーキテクチャ要素はシステムを構成するコアの「ブロック」であり、コネクタはこれらのコンポーネント間の通信パスと期待される結果を記述します。コミュニケーション、タスクフローは、システムが特定の要件を達成するためにこれらのコンポーネントとコネクタをどのように使用するかを説明します
システムを構築するために行われる、後から変更するのが難しい重要な決定が数多くあります。これらの決定は、システムを構築する前に行われ、システムが詳細に設計されたり、構築され始めたりすると、変更するのが困難または不可能になることは明らかです。それは非常に注意深く研究され、調査されなければなりません
。



B/Sアーキテクチャに基づいたシステム設計です

まず、C/S構造とは何ですか。

C/S (クライアント/サーバー) 構造。よく知られているクライアントとサーバーの構造です。両端のハードウェア環境の利点を最大限に活用し、クライアントとサーバーにタスクを合理的に割り当て、システムの通信オーバーヘッドを削減できるソフトウェアシステムアーキテクチャです。現在、アプリケーション ソフトウェア システムはクライアント/サーバーの 2 層構造になっていることが多く、Web アプリケーションの分散化が進んでおり、Web アプリケーションとクライアント/サーバー アプリケーションは同じ業務処理を行うことができます。モジュールは論理コンポーネントを共有するため、内部ユーザーと外部ユーザーの両方が新規および既存のアプリケーション システムにアクセスでき、既存のアプリケーション システムのロジックを通じて新しいアプリケーション システムを拡張できます。これが、アプリケーション システムの現在の開発方向です。

従来の C/S アーキテクチャはオープン モデルを採用していますが、これはシステム開発レベルでのオープン性のみであり、クライアントとサーバーの両方に特定のソフトウェア サポートが必要です。 C/S構造のソフトウェアは、ユーザーが真に期待するオープンな環境を提供できないため、OSごとに異なるバージョンのソフトウェアを開発する必要があり、また、製品のアップデートが非常に速く、同時に対応することが困難です。 LAN 上で 100 台以上のコンピュータを使用する。また、コストがかかり、非効率的です。

二番目に、B/S 構造とは何ですか。

B/S (Browser/Server) 構造はブラウザとサーバーの構造です。
インターネット技術の台頭によるC/S構造の変更または改善された構造です。この構造では、ユーザーの作業インターフェイスは WWW ブラウザを通じて実装され、トランザクション ロジックのごく一部はフロントエンド (ブラウザ) に実装されますが、主要なトランザクション ロジックはサーバー側 (サーバー) に実装されます。いわゆる三層構造。これにより、クライアント コンピュータの負荷が大幅に軽減され、システムのメンテナンスとアップグレードにかかるコストと作業負荷が軽減され、ユーザーの総所有コスト (TCO) が削減されます。

現在のテクノロジーから判断すると、LAN 内に B/S 構造を持つネットワーク アプリケーションを構築し、インターネット/イントラネット モードでデータベース アプリケーションを使用することは、習得が比較的簡単で低コストです。これは、さまざまな担当者がさまざまな場所からさまざまなアクセス方法 (LAN、WAN、インターネット/イントラネットなど) を通じて共通のデータベースにアクセスして操作できるようにする 1 回限りの開発であり、データ プラットフォームと管理アクセスを効果的に保護できます。権利、サーバーデータベースも安全です。特にJAVAなどのクロスプラットフォーム言語の出現後、B/Sアーキテクチャ管理ソフトウェアはさらに便利で、高速かつ効率的になっています。

3 つ目は、管理ソフトウェアの主流テクノロジーです。

管理ソフトウェア技術の主流技術も、管理思想と同様に、3つの開発期間を経ています。まず第一に、インターフェイス テクノロジは、前世紀の DOS キャラクター インターフェイスから Windows グラフィカル インターフェイス (またはグラフィカル ユーザー インターフェイス GUI)、そしてブラウザ ブラウザ インターフェイスに至るまで、3 つの異なる開発期間を経てきました。第二に、今日のすべてのコンピュータのブラウザ インターフェイスは直観的で使いやすいだけでなく、さらに重要なのは、ブラウザ プラットフォームに基づくアプリケーション ソフトウェアのスタイルは同じであり、ユーザーは高度な操作トレーニングを必要とせず、ソフトウェアは操作可能です。柔軟性が高く、識別が容易であることに加え、プラットフォーム アーキテクチャも、過去のシングル ユーザーから今日のファイル/サーバー (F/S) システム、クライアント/サーバー (C/S) システム、ブラウザ/サーバーへと発展してきました。 (B/S)システム。

2. C/S と B/S の比較

C/S と B/S は、今日の世界の開発モデル技術アーキテクチャの 2 つの主流テクノロジーです。 C/Sは米国ボーランド社が最初に開発し、B/Sは米国マイクロソフト社が開発しました。現在、この2つの技術は世界各国で習得されており、国内企業もC/S技術、B/S技術を活用した製品を数多く開発しています。どちらのテクノロジーも独自の一定の市場シェアと顧客ベースを持っており、その管理ソフトウェア アーキテクチャ テクノロジーは強力で先進的で便利であると述べており、多くの知識人が旗を振って叫んでいます。空を飛び回っていますが、慈悲深い人にはさまざまな意見があり、賢い人もいると言えます...全文の続き>>





http://www.bkjia.com/PHPjc/898820.html

www.bkjia.com

tru​​e
http://www.bkjia.com/PHPjc/898820.html

技術記事

laravel4.2の関連アーキテクチャ設計に基づいて、laravel4.2アーキテクチャ設計プロジェクトチームは最近laravelフレームワークを導入し、laravelの研究とプロジェクトアーキテクチャ設計に参加しました。個人的にはプロジェクトラックだと思います...