通常我們在做j2ee專案的技術架構時，通常會考慮一種分層的模型，目前非常流行的分層做法是控制層一般採用struts,springmvc，在業務層採用spring，ejb，在持久層採用hibernate,ibatis，jdbctemplate等。那麼為什麼要採用這種模型呢？這是我們需要考慮的問題。
其實採用分層模型主要目的是為了解耦，為什麼需要解耦？因為我們的專案是做應用解決方案的，它是一種定製化系統，而定製化系統的乙個比較明顯的特徵是需求的隨時變更，而為了去適應這種變更我們不得不從兩方面去解決這個問題，一方面是售前側，即讓售前與客戶溝通，盡量迴避需求的變更（相信做過售前的人會明白要想讓客戶明確自己想要什麼是有多麼地困難），而另一方面則是通過技術手段進行解決，即構建乙個靈活的，充分解耦的技術框架，以期能夠快速地對需求變更做出響應。自然，從技術層面來說，構建乙個分層模型的架構就是為了去適應需求的不斷變更，盡最大可能地進行解耦。為什麼分層模型能夠做到解耦呢？
因為對乙個系統進行分層處理，就是為了將乙個系統按其功能的最終呈現而進行職責的分離，不同的層次進行不同職責的功能劃分，比如展現層用來對資料進行展現的，控制層主要用於進行業務請求控制的，業務處理層主要用於進行業務邏輯處理的，持久層主要用於進行資料持久化和讀取的。為什麼這麼分呢？因為人們發現按這種方式對整個業務進行分離之後，帶來了很大的好處，比如某一處的修改，只會對本層有一定的影響，而不會影響其他層，這樣就做到了修改最少，風險最小。在乙個非常複雜的系統中，甚至於根據業務邏輯會構建更加多的層。
應用分層模型來解決實際的應用系統在我們所見的很多系統中都有所體現，比如我們所使用的計算機，就分為硬體層，硬體驅動層，作業系統層，應用軟體層，又比如osi網路協議的分層更是體現了分層所帶來的好處。所以我們在日常的系統構架中，採用分層來進行技術的解耦是很值得借鑑的。
但是，另一方面，我們需要注意一種濫用現象，即表明上看起來是採用了分層的，但實際上卻不是，而這種濫用的現象表現在兩個方面：
一是只是簡單地對各技術進行整合，而並不明白所採用的技術為何適用於此，即太過於依賴於技術本身，反而造成了對技術的耦合，這種情況下的典型表現是，對所採用的技術進行了相應地整合，同時進行了深度地封裝，從而導致了各層之間職責不分明，各層之間依賴過大。
二是跨層呼叫，即會出現一些通過一些基類的封裝繼承，而迴避了各層之間的功能職責，處理流程，甚至於會出現控制層能夠直接通過某種手段將持久層的資料用於進行展現層的呈現。
這種濫用現象的後果比較嚴重，太過於依賴於技術本身，尤其是開源技術本身，所帶來的是新員工入職時的工作上手理解熟悉過程較為複雜，另一方面則是人員的流失可能會造成一定程度的損失。並且在企業的進一步擴大發展中，固定的技術封裝也會對業務的擴充套件造成一定的阻礙。
大凡願意做程式設計師的人，一般其心理比較高傲一些，因為他們覺得這是乙個富有挑戰性的行業，很多時候，當乙個程式設計師在很好的解決某乙個問題時，會有很強的成就感，他們會因為這些興奮，而如果遇到解決不了的問題時，他們會想方設法也要進行解決，哪怕是不在工作時間，他們仍然會考慮問題的解決方法，因為這是由他們的性格特點決定了的。但是有一種問題程式設計師卻不想遇見，就是知其然而不知其所以然的問題，那麼這是一種什麼問題呢？
我們假定這樣一種工作情況，乙個程式設計師需要開發某個功能，這個程式設計師自然希望對這個功能的前因後果進行有效控制，做到心裡有數。但是此時有一種情況出現了，有人告訴他，應該怎麼配置，怎麼命名，怎麼繼承，怎麼呼叫，然後你的功能就算做完了。至於為什麼就算做完了呢？程式設計師也不清楚，他只知道就這麼用，如果他想更進一步地去了解，對不起，還真的有些難，因為面對乙個龐大的，深度封裝的框架，即使全部是開源的方式展現在你面前，他也無從下手，因為那些**不是他寫的，並且通常乙個基類有太多的方法了，甚至是乙個巨類，而基類彼此之間的呼叫又太複雜，關係太亂。面對這麼乙個沉重的框架，此時的程式設計師就會在心理產生一種嚴重的挫敗感沮喪感，他覺得即使我完成了某個功能，但我不知道為什麼就完成了，這就是知其然而不知其所以然的情況。這種情況帶來的後果是很嚴重的，一方面會讓程式設計師覺得沒有什麼成就，自己的技能也沒有進步，所帶來的後果是人員的信心喪失和流失，另一方面如果一旦出現某個特殊地需求，僅僅這麼配置繼承一下，是不能解決這種特殊需求的問題時，程式設計師就需要其他相關人員的配合，這不是另外一種耦合麼，即人員關係的耦合。
所以當我們在框架系統的技術框架時，所需要考慮的就是要迴避三種情況的耦合，即功能耦合（此種情況指的是類級別的耦合），技術耦合（此種情況指的是對技術過度依賴，過度封裝）以及人員耦合（此種情況指的是面對同一問題，需要多人進行修改,或者多人依賴於某個人提供的基類進行實現）。
三種故障還原模型
開啟sql server企業管理器，展開 資料庫 樹型選單，在任一資料庫上點右鍵，選擇 屬性 切換到 選項 標籤，我們就可以看到 故障還原 裡有乙個下拉列表框，包括 大容量日誌記錄的 簡單 完全 這就是我們要說的三種故障還原模型。簡單恢復，使用簡單恢復模型可以將資料庫恢復到上次備份的即時點，不過無法...
SDN三種模型解析
數十年前，計算機科學家兼網路作家andrew s.tanenbaum諷刺標準過多難以選擇，當然現在也是如此，比如軟體定義網路模型的數量也很多。但是在考慮部署軟體定義網路 sdn 或者試點之前，首先需要選擇要支援哪一種sdn模型。選擇錯誤就會浪費時間和成本，甚至可能將基於sdn的產品置於不利之地。在這...
三種執行緒池模型
half sync half async hs ha 將執行緒分為兩個部分，一部分專門處理非同步事件，另一部分專門處理同步事件。在網路伺服器裡，一般非同步事件指的是socket事件，同步事件指的是業務邏輯。leader follower lf 所有執行緒輪流監聽請求，監聽到後將監聽令牌傳到下乙個執行...