項目組不久前引進了laravel框架，本人參與了laravel的調研和項目架構設計。個人認為項目架構中基於laravel的有些設計還是比較實用和有借鑒性的，現將一些設計分享給大家，希望能和大家共同學習和探討。特別說明，本文並非對lavarel官方文檔的摘抄或總結。
1.1異常類
異常類統一放在app/lib/exception下，可以根據業務模塊再細分，對簡寫的異常類可采用一個文件多個異常類的形式，如：
class HttpRequestException extends Exception
{
}
class HttpResponseException extends Exception
{
}
1.2捕獲機制
可以在任意需要的地方做異常捕獲，如果不捕獲，異常將拋出至最外層。
拋出到最外層的異常，統一在app/start/global.php文件中定義handler
function handleException($code, $exception)
{
return Decorate::failed($code, null, $exception->getFile() . ':' . $exception->getLine() . ',' . $exception->getMessage());
}
App::error(function(HttpRequestException $exception, $code)
{
return handleException(-1007, $exception);
});
App::error(function(HttpResponseException $exception, $code)
{
return handleException(-1008, $exception);
});
1.3拋出機制
可在任意可觸發異常的地方，拋出異常。
RequestLog::request($url, $data, $start, $content);
if (!$content) {
throw new HttpRequestException($url . ':' . $data);
}
分三類log：接口調用log（RequestLog）、業務log（LogicaltLog）、調試log（DebugLog）。日志統一放在app/lib/log目錄下。其中RequestLog可用於接口調用的統計分析，LogicaltLog可以用於記錄邏輯數據，DebugLog用於輸出調試信息（也可直接用laravel自帶的\Log類）。
Laravle封裝了Queue用來做任務隊列，用來做異步處理非常方便。支持: "sync", "beanstalkd", "sqs", "iron", "redis"五種形式。建議用redis，超級好用。
隊列使用方法只要將任務類的類名壓入隊列，並且該任務類實現了fire方法，就可以使用了。
在fire($job, $data)裡，我們還可以拿到任務的嘗試次數$job->attempts() ，可以延遲任務響應時間$job->release(30);還可以刪掉任務$job->delete();。
最後特別提醒，可以通過laravel框架的artisan工具啟動隊列監聽：
php ../../../../artisan --env=devqueue:listen&
Filter可以用來做參數驗證、登陸態檢查、接口調用日志。
4.1參數檢查
在app /config/param.php裡定義各接口的參數驗證條件。驗證條件自行參考laravel文檔。
然後在app /Filter.php的Before裡，對每一個調用進行參數驗證，如：
App::before(function($request))
{
…
$res = Param::verification(Input::all(), $standard);
…
}
4.2接口調用日志
App::after(function($request, $response)
{
…
RequestLog::log($request, $response);
…
});
通常，我們的框架會有好幾套環境：正式、測試、本地、沙盒等，不同的環境配置肯定會有不同。Laravel允許在進程start的時候，指定當前配置環境，從而做到不同環境之間的自動切換。
1） 不同的環境配置目錄：
app\config\dev
app\config\formal
app\config\local
2）bootstrap/start.php指定需要的環境，例如測試環境dev
$env = $app->detectEnvironment(‘dev’)
3） 如何自動切換？
我們可以做到根據接口請求訪問的域名不同，指定相應的環境。比如dev.domain.com為測試環境，domain.com為正式環境。
軟件架構（software
architecture）是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。 軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向
對象領域中，組件之間的連接通常用接口_(計算機科學)來實現。
軟件體系結構是構建計算機軟件實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟件構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特征。
在“軟件構架簡介”中，David Garlan 和 Mary Shaw
認為軟件構架是有關如下問題的設計層次：“在計算的算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為“系統在其環境中的最高層概念”。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它並不僅注
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在Rational Unified Process 中，軟件系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過接口與不斷減小的構件與接口所組成的構件進行交互。
從和目的、主題、材料和結構的聯系上來說，軟件架構可以和建築物的架構相比擬。一個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來事實和管
理軟件產品的高級設計。軟件架構師定義和設計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程。
一般而言，軟件系統的架構（Architecture）有兩個要素：
它是一個軟件系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
第一、什麼是C/S結構。
C/S（Client/Server）結構，即大家熟知的客戶機和服務器結構。它是軟件系統體系結構，通過它可以充分利用兩端硬件環境的優勢，將任務合理分配到Client端和Server端來實現，降低了系統的通訊開銷。目前大多數應用軟件系
統都是Client/Server形式的兩層結構，由於現在的軟件應用系統正在向分布式的Web應用發展，Web和Client/Server應用都可以進行同樣的業務處理，應用不同的模塊共享邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現有的應用系統，通過現有應用系統中的邏輯可以擴展出新的應用系統。這也就是目前應用系統的發展方向。
傳統的C／S體系結構雖然采用的是開放模式，但這只是系統開發一級的開放性，在特定的應用中無論是Client端還是Server端都還需要特定的軟件支持。由於沒能提供用戶真正期望的開放環境，C/S結構的軟件需要針對不同的操作系統系統開發不同版本的軟件，加之產品的更新換代十分快，已經很難適應百台電腦以上局域網用戶同時使用。而且代價高，效率低。
第二、什麼是B/S結構。
B/S（Browser/Server）結構即浏覽器和服務器結構。它是隨著
Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶工作界面是通過WWW浏覽器來實現，極少部分事務邏輯在前端
（Browser）實現，但是主要事務邏輯在服務器端（Server）實現，形成所謂三層3-tier結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了用戶的總體成本（TCO）。
以目前的技術看，局域網建立B/S結構的網絡應
用，並通過Internet/Intranet模式下數據庫應用，相對易於把握、成本也是較低的。它是一次性到位的開發，能實現不同的人員，從不同的地
點，以不同的接入方式（比如LAN,WAN,Internet/Intranet等）訪問和操作共同的數據庫；它能有效地保護數據平台和管理訪問權限，服
務器數據庫也很安全。特別是在JAVA這樣的跨平台語言出現之後，B/S架構管理軟件更是方便、快捷、高效。
第三、管理軟件主流技術。
管理軟件技術的主流技術與管理思想一樣，也經歷了三個發展時期。首先，界面技術從上世紀DOS字符界面到Windows圖形界面（或圖形用戶界面GUI），直至Browser浏覽器界面三個不同的發展時期。其次，今天所有電腦的
浏覽器界面，不僅直觀和易於使用，更主要的是基於浏覽器平台的任何應用軟件其風格都是一樣的，使用人對操作培訓的要求不高，而且軟件可操作性強，易於識
別；再者，平台體系結構也從過去單用戶發展到今天的文件/服務器（F/S）體系、客戶機/服務器（C/S）體系和浏覽器/服務器（B/S）體系。
二、C/S和B/S之比較
C/S和B/S是當今世界開發模式技術架構的兩大主流技術。C/S是美國Borland公司
最早研發，B/S是美國微軟公司研發。目前，這兩項技術以被世界各國所掌握，國內公司以C/S和B/S技術開發出產品也很多。這兩種技術都有自己一定的市
場份額和客戶群，各家企業都說自己的管理軟件架構技術功能強大、先進、方便，都能舉出各自的客戶群體，都有一大群文人墨客為自己搖旗吶喊，廣告滿天飛，可
謂仁者見仁，智者......余下全文>>
