基於laravel4.2的相關架構設計,laravel4.2架構設計
項目組不久前引進了laravel架構,本人蔘與了laravel的調研和項目架構設計。個人認為項目架構中基於laravel的有些設計還是比較實用和有借鑒性的,現將一些設計分享給大家,希望能和大家共同學習和探討。特別說明,本文並非對lavarel官方文檔的摘抄或總結。
1異常處理
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);
}
2日誌記錄
分三類log:介面調用log(RequestLog)、業務log(LogicaltLog)、調試log(DebugLog)。日誌統一放在app/lib/log目錄下。其中RequestLog可用於介面調用的統計分析,LogicaltLog可以用於記錄邏輯資料,DebugLog用於輸出調試資訊(也可直接用laravel內建的\Log類)。
3任務隊列
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&
4 Filter
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);
…
});
5環境切換
通常,我們的架構會有好幾套環境:正式、測試、本地、沙箱等,不同的環境配置肯定會有不同。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)。
所謂架構元素,也就是組成系統的核心"磚瓦",而連接器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果,任務流則描述系統如何使用這些元件和
連接器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的,商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出,而一旦系統開始進行詳細設計甚至建造,這些決定就很難更改甚至無法更改。顯然,這樣的決定必定是有關係統設計成敗的最重要決定,必須經過非常謹慎的研究和考察。
什是基於B/S架構的系統設計
第一、什麼是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技術開發出產品也很多。這兩種技術都有自己一定的市
場份額和客戶群,各家企業都說自己的管理軟體架構技術功能強大、先進、方便,都能舉出各自的客戶群體,都有一大群文人墨客為自己搖旗呐喊,廣告滿天飛,可
謂仁者見仁,智者......餘下全文>>
http://www.bkjia.com/PHPjc/898820.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/898820.htmlTechArticle基於laravel4.2的相關架構設計,laravel4.2架構設計 項目組不久前引進了laravel架構,本人蔘與了laravel的調研和項目架構設計。個人認為項目架...