最近在做專案階段性的測試和上線，還有指導實習生做專案，框架計畫雖然一直在進行，但是都是很基礎的研究工作，並沒有太系統化的成果，所以也就一直沒動手寫這個系列。
說實話，我在選型上犯了難。一直以來都用的是傳統的三層架構，一是比較成熟，十多年前上大學的時候已經在學習並運用了，而且後來開發的幾十個專案中並沒有出現太多的問題，當然也許是和沒什麼大型的專案經歷有關。二是三層已經很符合專案工程化的概念，無論是運用tdd還是ddd，總有新人理解和上手不易，實際操作效果不明顯的問題。
關於第二點，我可以舉去年進行的乙個專案例子來說明。去年開始了乙個新專案，因為當時我負責需求整理和業務分析，框架是公司的架構師負責的，他也用的是3層的方式去搭建整個架構，利用指令碼從資料庫生成基礎**，手動編寫業務邏輯和頁面邏輯，其實這個架構很簡單，我當時大概看了下，沒什麼問題，就確認使用了。專案開始後進行了人員的擴充，有多年經驗的老程式設計師，也有還沒畢業的實習生，開始之前，我們給新員工進行了短暫的框架培訓。說實話，效果並不是很好，雖然是傳統的三層，但是我們還是對框架的一些實現做出了約束，過後開發中發現即使是有經驗的程式設計師，也並沒有嚴格按照約束來進行開發。比如將大量的業務邏輯放在controller，或者db層放置了不少查詢邏輯。如果是在沒研究新的框架以前，我並不會覺得有太多問題，頂多在codereview的時候，把比較嚴重的地方進行重構。但是我在後來思考的時候想，架構不是應該更多從技術角度去進行約束，人為的**控制只是輔助嗎？也就是說，如果架構搭建得好，程式設計師都應該會覺得在這個層或者模組內實現業務邏輯很方便，在另乙個層次模組內進行展現更合適.
做菜不實際掌過勺就沒辦法注意火候，所以在確定最終選型前，我還是從最熟悉的方式做起.看看從三層過度到tdd或者ddd應該是怎樣的。我建立了如下的專案結構
1.資料層。和往常一樣，提供最基礎的資料訪問服務
2.業務層。業務和大部分的資料轉換放置在這裡
3.基礎設施層。提供資料實體對映以及生成模板，轉換的資料模型，還有部分基礎的非邏輯性的常用函式以及部分初始化資料
4.展現層。mvc,測試工程等等
下一章節先從資料層說起
Scala框架選型
我所知道的scala持久層框架有 1 slick typesafe出品 2 squeryl 3 anorm play的持久層 4 scalaactiverecord 基於squeryl之上 5 circumflex orm 6 activate framework 不只是scala版的hiberna...
UI框架選型
最近公司的乙個新專案要進行ui框架的選型，我把選型的思路和過程跟大家分享一下。在選型之前，我們先要定一下選型的標準，就像人生一樣，想清楚 自己要的是什麼 是最重要的。選型的標準分為幾部分 業務是根本，和大部分的技術一樣，框架沒有好壞之分，只有適合與不適合。我們專案是乙個通訊類的監控專案，使用者群是移...
通訊框架選型
最近想選擇乙個通訊框架，net體系裡，大概在網上找到dotnetty，akka.net和國產的supersocket。最先看了supersocket，基本接受他的api設計。但最後評估了一下開源生態，supersocket更新的好像比較緩慢，重要的是還不支援.net core，最後還是放棄了。另外看...