duwamish7架構分層分析
1.總的感覺：
使用的不是一種純粹的oo的實現方法，基本上可以看作一種組合良好的事務指令碼的寫法。
但是這種寫法我個人不是很推薦，關鍵有下面幾點遺憾：
1)沒有用oo的寫法，而將實體的資料部分放在了common,而將它的方法又散落到了businessrules/businessfacade。(按duwamish7的分層方法也說得過去，但是總是感覺不大舒服)
2)用自定義的dataset來傳遞資料，dataset定義得較複雜，不易理解，估計也不好維護。
2.businessfacade:業務外觀層
以功能分，提供若干系統的功能的外觀類,如productsystem等。
1).bf層可以看作是控制類的層，它呼叫dataaccess層的資料訪問類來訪問資料庫，由此完成特定的業務操作，如crud操作。
2).侷限性：在系統邏輯較少時，可以直接用productsystem類來表示一類服務，但是系統功能多時，就必須分出多個類來了。
這個外觀層做得很有意義，可以提供乙個更明確緊湊的「服務層」給客戶呼叫，而且也可以盡可能減少將業務邏輯放在ui層來實現。
3.dataaccess層：
資料庫訪問層，也就是寫sql調ado.net的相關類訪問db的層
1).失敗的地方：每個類的方法都直接寫ado.net的方法來訪問資料庫，沒有提供乙個dbhelper類來統一訪問。
2).命名也失敗：db層的類最好以db字尾，如bookdb.cs,否則與businessrules等幾個工程的類容易混淆，增加不必要的麻煩。
4.common層：
可以看作是乙個實體類層。自己定義了dataset，bf、db、rule層就用那些dataset來傳遞資料。
不是很舒服，主要是：
1)這種實體類只有資料沒有行為，算是"啞類",除了傳遞資料外沒有其他用處。通常實體類對映現實的乙個事務，oo的通常做法是資料和方法是放在乙個實體類裡的，這樣又必須一些實體對應的行為放到bf/rule層去了，不是推薦的做法。參考所謂的「資訊專家模式」。
2).用dataset來表示乙個實體，裡面又有若干datatable,這種用法個人是比較少見，一般都是直接用單個datatable來做了。我只在winform的datagrid裡用過dataset，那主要是因為datagird的datasorce就設為dataset了，方便使用。
5.businessrules 業務規則層
bf層直接呼叫db層完成了一部分crud的操作，但涉及到較複雜的業務規則計算的邏輯，放在了rule層，而不是直接放在bf層。rule層也調db來訪問資料庫。這可以算是乙個亮點，因為它把一些複雜業務邏輯抽出單獨放在一層裡了，否則就得像通常我們寫三層**時全放在「業務邏輯層」了。這樣如果要修改這些業務邏輯就很方便高效了。(看了duwamish7終於知道vs.net的企業模板自動生成的businessrules是搞什麼的，最近想優化一下公司**的分層，原本有些「服務層」的邏輯沒地方放本想放在rule裡的，現在看來不太適合了)
上面提了我個人感覺到若干duwamish7的不佳的地方，因為最近考慮一下架構分層，匆匆看看所感，有謬論歡迎指正。現在才談duwamish7題材老了點，作為個人一點資料備份暫且還是post上來吧。
JEECMS 2 3 2架構分析
對於乙個程式設計人員來說，這種東西的內在架構還是值得一看的。不過也完全沒有那麼神秘或者說深奧。今天我就抽出1個小時，剖析一下 jeecms 2.3.2這個j2ee版的開源cms。之所以選擇這個開源系統，是因為有人號稱，這個系統比我之前自己設計的架構還要高乙個檔次。所以，我也很想一 竟。看看到底有沒有...
Android OkHttp3架構分析
在okhttp3中，其靈活性很大程度上體現在，可以intercept其任意乙個環節，而這個優勢便是okhttp3整個請求響應架構體系的精髓所在 okhttp 中的對所有的任務採用namedrunnable，約束每個執行單元給出對應的業務名稱，以便於執行緒維護。1.非同步請求執行緒池 okhttp d...
linux學習筆記 coretx A7架構
使用正點原子linux開發板學習，記錄 第六章coretx a7 mpcore 架構 學習過程中的重點 疑惑 1 cortex a7 mpcore 處理器支援 1 4 核 2 l1 cache 高速緩衝儲存器，有關介紹參考 又分為指令cache和資料cache 3 snoop control uni...