後臺框架--框架

摘自：http://www.iteye.com/topic/1134829#2411086框架層面：

 

SOA
在這一篇中會逐個介紹一下本身對這些XXX的理解，其實每個理念都不是莫名其妙產生的而是有產生背景的，這些時髦的名詞不是用來炫耀的，而是真正要理解它們是幹什麼的，而且框架千萬不能亂用理念也千萬不能亂用，並非把全部的這些都用上你的系統纔是一個牛逼的系統，必定要適合纔是最好的，而且要保持簡單可靠的原則。所謂SOA，字面上來講是面向服務的架構。有的人不說SOA其實他已經SOA了，有的人大談SOA但其實只是在用Web服務，SOA可大可小。你能夠認爲服務調用就是SOA了，也能夠認爲服務調用只是SOA中的很小一部分。我的以爲SOA的理念是說，把業務邏輯從類庫的封裝提高到服務的封裝，而且經過不一樣的信道不一樣的編碼格式來提供服務，使異構系統之間也能重用服務，說白了就是讓代碼從本機重用提高到了跨機器的重用。從最簡單的來講，把組件封裝成自制的服務，經過交換消息來使用服務提供的功能，那麼就是SOA了，但這也僅僅是SOA的開始，好比你是否想過下面的問題怎麼解決？

你的服務是否能夠被外部的異構系統使用？
若是你的服務又須要調用另外的服務，怎麼處理複雜的調用關係，怎麼監控整個調用過程？
服務調用怎麼歸入事務的控制中？
服務愈來愈多，接口愈來愈多，怎麼知道應該調用哪一個服務哪一個接口？
接口的版本升級了怎麼辦？
服務有太多人調用，怎麼進行負載均衡，怎麼限制調用人數？
怎麼作安全，限制服務的匿名調用？
服務怎麼進行測試？
服務調用失敗後怎麼辦？
服務怎麼進行升級和從新部署？
所以，SOA其實不只僅是調用服務，在監控和治理上有不少事情要作，SOA可大可小。無論怎麼說，從理念上來講，SOA確實是一種進步，複雜邏輯都封裝成服務，一個複雜的系統可能調用不一樣的服務就能夠完成了，每個服務都是自治的，很好的下降了系統總體的複雜度。其實一個複雜的系統若是複雜度在10000的話，那麼分紅四層實現10*10*10*10就能夠大大下降複雜度，每一層只要作好10複雜度就行了，由上層來調用下層。OSI若是不是七層模型，而是一層模型的話很難想象怎麼去處理整個複雜的過程。
示例資源
 

RPC
字面上來講就是遠程過程調用，RPC（這裏咱們說廣義上的RPC）也能夠是SOA實現的一種方式，SOA並不必定都經過Web服務實現。從實現原理上來講RPC其實並非很複雜，無非就是客戶端有一個代理，收集客戶端要調用的遠程方法以及參數，而後序列化成消息提交到遠程，到了遠程以後把消息反序列化，動態執行客戶端所須要的方法（固然也包括建立對應的對象），而後把結果經過另一個消息返回給客戶端，固然其中的細節太多了。從客戶端和服務端交換數據依賴的信道來講通常使用TCP或HTTP，也可能會是UDP。

ORM
對象關係映射解決面向對象系統和數據庫阻抗不匹配的問題，你們都知道的ORM的定義。這裏我想說的是ORM的出發點是好的，並且在某些應用中ORM確實能夠改善代碼可讀性，增長編碼效率，我的認爲ORM是有使用狀況的，不是全部的數據訪問都適合使用ORM框架的，Java的SSH也有那麼一點誤導，Struts不是實現MVC的惟一方法，Spring不是實現IOC的惟一方法，Hibernate也不是實現數據訪問的惟一方法，我以爲ORM：

它適合領域複雜的，表多的，表之間關係多的，訪問量相對較小的，企業應用。
它不適合業務相對簡單，表之間關係很少，訪問量超大的互聯網應用。
對於ORM來講要入門是簡單的，可是要用好不是這麼容易的：

若是沒有正確使用極可能致使產生大量的SQL語句，而使用者還不知道。
若是沒有正確使用極可能會拉取過多沒必要要的數據，而使用者還不知道。
若是沒有正確使用極可能會產生性能不高的SQL語句，而使用者還不知道。
所以，即使是使用ORM也要對ORM產生的SQL語句張一個心眼，而且咱們須要瞭解ORM中是如何作延遲加載、級聯加載、主鍵緩存的，只有瞭解了這些機制才能真正用好ORM，若是對ORM不熟悉，若是在作互聯網系統我以爲仍是太平點吧，SQL語句精準高效。固然有的人要說了用SQL的話業務邏輯就可能不在代碼中了，其實這個仍是看SQL語句怎麼寫的，若是把SQL只是當作數據庫和程序的溝通橋樑的話這不是問題，若是在SQL裏面作一些判斷作一些計算那就是本身的事情了。示例資源

 

IOC
控制反轉依賴注入不是嘴上說說的，它是一個很是實用的理念。有的人即便在使用了IOC以後尚未意識到爲何要使用IOC，我總喜歡在面試的時候問爲何要用容器來建立對象，本身手動new出來有什麼很差？有的人回答是手動new出來的性能不高，容器建立的是惟一的對象，那我就會問本身寫一個單例的對象也是同樣的，爲何要容器建立？其實這樣的理解是有誤的。我的認爲管理對象的生命週期只是IOC容器的一個做用，IOC容器的意義在於：

管理了對象之間的關係。在OO中組合頗有用，若是對象之間有複雜關係的話，那麼咱們就必須在new對象的時候來構建這種關係，這些關係其實都寫死在代碼中了。而且咱們經過代碼會直接把實際的類型寫死，下降了針對接口編程的意義。若是能在配置文件中根據本身的需求來配置這種關係，由容器動態建立對象和對象之間關係的話，那麼咱們就把代碼中依賴提取到了外部，由外部注入進去。在一個分層的應用程序中，咱們不只僅注入平行層級的對象，還能夠注入下級對象，實現從上到下的自動注入，整個系統就很是靈活。
管理了對象的生命週期。有的時候出了單例或是new出來的對象，還會有根據線程、根據請求來的特殊聲明週期的對象，若是手寫代碼來管理聲明週期一來很麻煩，二來也不方便調整，經過容器來管理對象的聲明週期簡單高效，而且咱們很容易對容器進行擴展提供不一樣的聲明週期的字典便可擴展生命週期的類型。
 

AOP
面向切面編程對於職責分離和提升可測試性都很重要。通常來講代碼有兩種方式織入，靜態的和動態的。所謂靜態的就是在編譯以前直接改了要包裝的類，而後把關注點的入口方法封裝進去一塊兒編譯的編譯時加強。所謂動態的就是在運行的時候動態修改代碼動態編譯的運行時加強。一旦有了AOP，那麼咱們的事務、日誌、權限、緩存之類和業務無關的代碼就能夠不出現和混在業務代碼中了，根據須要進行配置就能夠對任意的代碼進行這些橫切關注點的加強。一旦這些代碼有修改，咱們也只須要修改配置，而不是在代碼中的幾千個幾萬個地方去查找修改。

 

MVC
MVC對於網站特別是互聯網網站來講是一種很是好的裏面，MVC的優勢體如今：

職責分離，再也不是全部的代碼都混在一塊兒了，V和C的分離尤爲重要。
職責分離早就了能夠進行單元測試，可測試性也是重要的一環，對C能夠進行單元測試是很是重要的。
大多數MVC框架都提供了AOP的織入點，在實現職責分離的時候還能實現橫切關注點的自動執行和可替換性。
在實現MVC的時候咱們不只僅是能把MVC框架用上去就行了，要儘量實現：

C中的諸如緩存、權限、日誌之類的橫切關注點務必提取出來經過AOP實現，不要和C的其它業務性邏輯混在一塊兒。
C中的Action能夠重用的儘可能重用，Action的結果能夠重用的也儘可能重用。
能夠考慮MVC和IOC相結合，把C用到一些服務或DAO動態注入進來。
對於V儘可能確保V中不要有後端代碼，V可讓前端開發直接編輯，由後端開發嵌入比較簡單的Tag。若是VM明確的話，前端甚至能夠直接寫V。
 

TDD
測試驅動開發又是一個不小的概念。各類平臺也有各類框架來實現Mock來實現單元測試。工具再好沒有正確的編碼理念也是沒用的，要實現全部的代碼都能經過單元測試來驗證必要的幾個因素包括：

程序沒有很複雜的上下文環境，或者說上下文環境是能夠被模擬的，不然怎麼測試？
程序模塊的職責是單一的清晰的，若是一個模塊作了幾十件事情，有幾百個分支的話是很難測試，測試的粒度越是細越是容易測試。
針對如今大多數項目沒法進行TDD，甚至沒法進行單元測試的緣由是由於每每時間很趕，只能有時間實現最基本的業務邏輯，而單元測試其實編碼的時間不會比實際的編碼少的，甚至更多。我的認爲能夠根據項目的性質不一樣來看，若是這個項目原本就是CRUD的，或者是一個臨時的項目，單元測試TDD的意義不大。但若是這個項目是一個要被不少人使用的類庫或者框架性質的項目，沒有單元測試是沒法想象的：

若是一個類庫提供了100個功能，你不可能在修改了一個點以後就去手動測試一下這100個功能，必須經過自動化的手段進行。
類庫須要確保在全部的邊界狀況都考慮到，手動測試或者黑盒測試是很難覆蓋全部狀況的。
若是你的類庫沒有提供單元測試，類庫的使用者怎麼在他們的執行環境來驗證類庫的可用性呢？所以還不只僅是給本身用，別人還要使用你的單元測試來確保類庫在本身的運行環境下能夠正常工做。示例資源
 

其它
在這裏先想總結一下，我的以爲這麼多XXX中最須要有的就是MVC和IOC了，至於AOP有了固然更好，至於ORM和SOA則是看需求了，對於TDD麼若是你在寫一個類庫或框架那是必須的，不然很難想象這套代碼的穩定性會有多高。除了上面提到那那些XXX其實還有不少做爲基礎框架須要實現的東西，之前畫過一個腦圖參考：http://www.iteye.com/topic/1134828。做爲框架我以爲有一些要素是須要知足的：

儘可能保持框架對外的接口是很簡單的，複雜的東西應該在框架內部處理掉，對框架的使用者透明。
框架的異常處理要完善，日誌記錄要完善，框架因爲是對開發者透明的，所以最好在異常信息和日誌信息中寫明要調用者和框架的使用者怎麼樣去作才能解決這個問題而不是僅僅是說出了什麼錯。
一個完善的框架應該內建性能檢測機制，或者提供http的接口可讓外部瞭解到框架內部的運行情況。
框架要作好測試，確保在不一樣的線程環境和不一樣的配置狀況下框架都能正常運行。
框架最好有性能測試，讓使用者明確這個框架能提供的性能，以便正確判斷是否能夠知足本身的需求。