架構計劃随筆 二.選型

　　最近在做項目階段性的測試和上線，還有指導實習生做項目，架構計劃雖然一直在進行，但是都是很基礎的研究工作，并沒有太系統化的成果，是以也就一直沒動手寫這個系列。

　　說實話，我在選型上犯了難。一直以來都用的是傳統的三層架構，一是比較成熟，十多年前上大學的時候已經在學習并運用了，而且後來開發的幾十個項目中并沒有出現太多的問題，當然也許是和沒什麼大型的項目經曆有關。二是三層已經很符合項目工程化的概念，無論是運用TDD還是DDD，總有新人了解和上手不易，實際操作效果不明顯的問題。

　　關于第二點，我可以舉去年進行的一個項目例子來說明。去年開始了一個新項目，因為當時我負責需求整理和業務分析，架構是公司的架構師負責的，他也用的是3層的方式去搭建整個架構，利用腳本從資料庫生成基礎代碼，手動編寫業務邏輯和頁面邏輯，其實這個架構很簡單，我當時大概看了下，沒什麼問題，就确認使用了。項目開始後進行了人員的擴充，有多年經驗的老程式員，也有還沒畢業的實習生，開始之前，我們給新員工進行了短暫的架構教育訓練。說實話，效果并不是很好，雖然是傳統的三層，但是我們還是對架構的一些實作做出了限制，過後開發中發現即使是有經驗的程式員，也并沒有嚴格按照限制來進行開發。比如将大量的業務邏輯放在controller，或者DB層放置了不少查詢邏輯。如果是在沒研究新的架構以前，我并不會覺得有太多問題，頂多在codereview的時候，把比較嚴重的地方進行重構。但是我在後來思考的時候想，架構不是應該更多從技術角度去進行限制，人為的代碼控制隻是輔助嗎？也就是說，如果架構搭建得好，程式員都應該會覺得在這個層或者子產品内實作業務邏輯很友善，在另一個層次子產品内進行展現更合适.

　　做菜不實際掌過勺就沒辦法注意火候，是以在确定最終選型前，我還是從最熟悉的方式做起.看看從三層過度到TDD或者DDD應該是怎樣的。我建立了如下的項目結構

　　

　　使用了部分園友使用的搭建示範架構的元件——EF，Unity或者autofac，automapper，看看搭配起來合不合适。

　　1.資料層。和往常一樣，提供最基礎的資料通路服務

　　2.業務層。業務和大部分的資料轉換放置在這裡

　　3.基礎設施層。提供資料實體映射以及生成模闆，轉換的資料模型，還有部分基礎的非邏輯性的常用函數以及部分初始化資料

　　4.展現層。mvc,測試工程等等

　　下一章節先從資料層說起

　　

轉載于:https://www.cnblogs.com/redfoxhuang/p/4395530.html