這部分主要是說表現層和併發。
第四章 web表現層模型-
檢視-控制器（輸入控制器）
控制器處理請求訊息，模型負責領域邏輯，檢視基於模型建立應當訊息。
控制器輸入控制器和應用控制器
檢視三種模式：轉換檢視，模板檢視和兩步檢視
兩種選擇：
1）使用轉換檢視還是模板檢視。
模板檢視：允許在網頁的結構中編寫表現層，並允許在網頁中嵌入標籤，用以標明網頁中的動態內容導向到**。
優點：靈活性。
缺點：**混淆，難以維護。
解決辦法：使用伺服器頁面技術時，使程式的邏輯獨立與網頁。
轉換檢視：使用程式的一種轉換風格。
如，xslt
2）選擇單階檢視還是選擇兩步檢視。
單階檢視：為每個螢幕都準備乙個檢視元件
兩步檢視：把這一過程分層兩個階段，由領域邏輯產生乙個邏輯螢幕，然後把他傳送html網頁中。其中每個螢幕都有乙個第一階檢視，而整個程式中只有乙個第二階檢視。
優點：可以全域性改變html頁面。
缺點：不容易提取邏輯螢幕結構。
如果web應用程式提供的服務由多種前端使用者使用，執行兩步檢視更好。
輸入控制器模型
兩個責任：處理http請求訊息，根據請求訊息來決定下一步做什麼。
兩種模式：
1）為web站點的每乙個頁面都準備乙個輸入控制器。
2）把兩個職責分開。
第五章併發
軟體開發中最辣手的問題。
用多執行緒或多程序操作同一資料，都會遇到併發問題。
離線併發：多資料庫事務中資料操作的併發控制（
在跨事務的資料處理中管理併發問題）。
5.1併發問題
併發的本質問題：
更新丟失：
不一致行：讀取兩份各自正確的資料而在同一時間相互矛盾。
上面的問題會導致
正確性的失敗。但需要考慮靈活性。
5.2執行語境
請求和會話
從與外界互動的角度看，有兩個重要的執行語境，請求和會話
。 乙個請求對應於軟體工作的外部環境發出的單個呼叫。
一次會話是客戶端和伺服器端的之間一次長時間互動。
它可以是乙個請求，但通常是由一系列使用者認為邏輯上有關聯的請求構成的。
一次會話通常從使用者登入開始，然後使用者進行各種操作。在會話結束的時候使用者退出。
程序（process
）和執行緒（
thread
） 兩個作業系統的術語：程序（
process
）和執行緒（
thread
） 程序：通常是乙個重量級的執行語境，將其正在處理的內部資料與外部隔離開。
執行緒：輕量級的活躍執行單元，乙個單獨的程序裡面可以存在多個執行緒。
執行緒通常是共享記憶體的，會導致併發問題。
事務處理資料庫的時候另一重要語境，事務。
可以當多個請求當單個請求來看待。
5.3隔離和不變性
對企業應用來說，兩個非常重要的解決方案：乙個事隔離，乙個是不變性。
隔離併發問題發生在多個執行單元訪問同一片資料的時候。使用隔離來劃分資料，使得每一片資料只能被乙個執行單元訪問。作業系統為每個程序單獨分配一片記憶體。
使用檔案鎖也是隔離。
不變性識別那些不變的資料。
5.4樂觀併發控制和悲觀併發控制
當有一些可變資料無法隔離的時候。可以使用兩種形式的併發控制策略。
例，persona和personb都要編輯檔案file。
樂觀併發控制：
都能得到乙份檔案的拷貝，並且可以自由編輯檔案。第乙個完成編輯的人可以直接儲存檔案。當第二個人開始提交修改時，併發策略開始起作用。檢測兩份修改的衝突，並拒絕提交。由第二個人指出怎樣處理這種情況。
悲觀併發控制：
只要有人先取出檔案，其他人就不能對該檔案進行編輯。
可以把樂**成是衝突檢測
的，把悲**成是衝突避免
的。 比較
： 悲觀的問題是減少了併發的程度。
樂觀更加自由一些，只有在提交的時候才有可能遇到阻礙。問題在於衝突的時候如何處理。
選擇標準：衝突的頻率和嚴重性
如果衝突很少，或者衝突的後果不嚴重，那麼選擇樂觀鎖。因為能夠得到更好的併發。而且更容易實現。
5.4.1
避免不一致性
1）悲觀鎖策略通過讀加鎖和寫加鎖處理不一致問題。
共享鎖（read lock，讀鎖）可以一次多個人對同乙份資料加鎖。但只要有人得到乙個讀鎖，其他人就無法再得到寫鎖。
其他人能讀不能寫
排他鎖（write lock，寫鎖）一旦有人得到寫鎖，其他人就不能得到兩種鎖中的任何一種。
其他人不能讀也不能寫
2）樂觀策略將衝突檢查建立在資料的某種標記上，可能是時間戳，也可能是順序計數器。
3）時序讀
也可以處理不一致問題。
每次讀的時候根據使用時間戳等作為約束條件。
5.4.2
死鎖 對於悲觀技術有乙個很特別的問題就是死鎖。
解決辦法：
1）超時控制
達到時間限制，鎖失效。
2）檢查機制
檢查死鎖，犧牲一方。
3）死鎖的原因是人們在得到了乙個鎖的情況下還想得到更多的鎖（或者是想從讀鎖公升級為寫鎖）。因此防止的方法就是在開始的時候得到所有鎖，之後不允許再得到鎖。
4）可以硬性規定每個人獲得鎖的順序。
5.5
事務transaction
1）事務是乙個有邊界的工作序列，開始和結束都有明確定義。
2）所有相關資源在事務開始和結束時都保持一致。
3）每個事務要不全部完成，要不什麼都不做。
5.5.1 acid
軟體事務經常使用acid的屬性來描述。
a 原子性
在乙個事務中，動作序列的每乙個步驟要麼是全部成功，要麼是全部回滾。
c 一致性
在事務的開始和結束的時候，系統的資源都必須處於一致的，沒有被破壞。
i 隔離性
乙個事務直到他成功提交以後，它的結果對任何其他的事務才是可見的。
d永續性
乙個已提交事務的任何結果都必須是永久的。
5.5.2
事務資源
事務資源：可以進行事務處理的任何資源。
短事務：為了增加吞吐量，事務盡可能短。盡可能不要讓事務跨越多個請求。
通常在請求開始時啟動事務，請求結束時提交事務。
長事務：跨越多個請求的事務。
延遲事務：盡可能晚的開啟事務，應在事務外完成讀取資料的操作，只在修改資料的時候啟動事務。
使用事務時，必須清楚的知道被鎖住的到底是什麼，資料庫一般是鎖住被訪問的行。如果乙個事務鎖住許多行，資料庫無法處理那麼多鎖，只能將行鎖公升級到鎖住整個表。從而將其他事務鎖在外面。
鎖公升級：這種鎖公升級對併發影響很大，這也是為什麼不能在領域層超類級別上使用「物件」表的原因。這樣很容易導致鎖公升級，而鎖住該錶後，其他對資料庫的訪問也就阻塞了。
這個說法第一次聽到，確實讓人茅塞頓開。
5.5.3
減少事務隔離以提高靈活性
四種隔離級別
隔離級別
髒讀
不可重複讀
幻讀
讀未提交是是
是讀已提交否是
是可重複讀否否
是可序列化否否
否5.5.4 業務事務和系統事務
離線併發問題：自己為跨系統事務的業務事務提供acid支援。
最容易解決的是原子性和永續性。最麻煩的隔離性（一致性）。
5.6離線併發控制的模式
1）樂觀離線鎖
，在業務事務間使用樂觀的併發機制。
缺點：只能在提交資料時才發現業務事務將要失敗。
2）悲觀離線鎖
，可以盡早的發現錯誤，但難以程式設計實現，而且會降低靈活度。
5.7應用伺服器併發
應用伺服器自身的程序併發。
處理辦法：
1）每會話一程序
，各個程序之間完全隔離，問題是大量資源的消耗。
可以使用程序池來提高利用率。
2）使用程序池的每會話一程序
方式能使用更少的資源處理同樣多的會話。
3）每會話一線程
，最重要的是建立和進入乙個隔離區，最常用的方法是讓執行緒每次都建立新的物件來處理請求，以保證這些物件不被其他執行緒訪問（比如
靜態變數）。
《企業應用架構模式》介紹部分筆記
架構 架構一般來說意味著 從最高層將系統分解成多個部分。一旦作出就很難改變的決定。ralph johnson說 架構是一種主觀的東西，是專案專家開發人員對系統設計的一種共同理解。通常，共同理解是指系統包含哪些主要元件以及這些元件相互之間如何互動。martin認為架構模式中最重要就是分層。企業應用程式...
《企業應用架構模式》 閱讀筆記2
這方面的理論知識可以參考eric evans的 領域驅動幹設計 軟體核心複雜性應對之道 實踐相關的內容可以參考vaughn vernon的 實現領域驅動設計 也可以參考我的系列部落格 ddd 使用領域驅動設計思想實現業務系統。初學者在實踐ddd的時候，首先需要改變思維方式，業務領域的分析和建模是關鍵...
《企業應用架構模式》 分層
在系統的分層組織方式下，上層通過介面使用下層定義的各種服務，下層對上層一無所知。每一層都對自己的上層隱藏其下層的細節，因此第4層無需知道第2層的細節。分層的好處 1.可以專注理解某一層，無需過多了解其他層次 2.可以替換某層的具體實現，只要前後提供的服務 介面 相同即可 3.可以將層次間的依賴性減到...