如果您是初次閱讀這個系列，請先去《index & writing plan》查詢並閱讀「架構設計系列」的前兩篇文章，順序閱讀會使您有更好的閱讀體驗
正文開始
controller其實就是接收service處理過的資料，並且呈現給頁面；因為業務邏輯已經在service中處理過了，所以controller無非就是將資料稍微修改一下，比如說日期的顯示方式，2012/11/15，還是2012-11-15
而view，也沒什麼和構架相關的東西，一筆帶過
我這篇文章真正想寫的是我和我同事的討論
同事提出了乙個想法：按照之前的架構，每個學校我都要去寫一套controller與view，而其實這裡面並不是所有頁面都有差異的。比如說teacherlist頁面，雖然不同的學校有不同的差異字段，但是list頁面不一定會將差異字段顯示出來。比如說現在a、b、c三所學校teacherlist要顯示的字段是一樣的，那麼我還去寫3套controller和view，是不是顯得很傻
根據分析老系統，大概有30%以上的頁面是沒有差異的
這個構架的大體思路就是：什麼不同，我就重寫什麼；有且只在需要的時候重寫
看起來很美妙，整個構架相當精煉，沒有多餘的地方，但是真的是無懈可擊的麼？
以下是我和他的skype的聊天記錄：
我：有3種層次：
1、業務邏輯不一樣，重寫service
2、頁面邏輯不一樣，調整controller
3、頁面不一樣，重寫頁面
可以這樣整理吧
他：我想的是這樣
但不知道實際開發時會不會搞亂。
我：我覺得還是弄簡單點好吧
我自己都覺得理解起來有些困難
他：不知道怎樣才能簡單。
route 重定位這裡本來就比較複雜的。
調整action 很容易搞亂。
我：我再想想
他：稍微多寫點東西，專案結構簡單。這樣應該好一點
我：是啊，簡單的往往是最好的
我聽說過一種說法，說是你把系統構架圖畫出來
如果系統構架圖漂亮，那麼就是乙個好系統
他：action 配置多會比較麻煩
盡量少點像剛才的那種 view 和controller迴圈重定位的東西。
我：要不還是每個城市寫一套controller和view算了
t4模板弄好的話，這個也挺快的
他：這個再想想，到時候去會議室討論吧。
是的，我們都認為這個構架的最大弱點在於複雜
連設計構架的人都會被弄得思維混亂，那麼幾乎可以確定這個構架對於使用者來說，相當的不友好，雖然減少了**量，但是增加了邏輯負擔
最後我們討論的結構是：維持原有構架
因為權衡之後，覺得依靠t4模板，寫controller和view並不是多重的負擔
就此，整個專案的構架都這樣定下來了，準備應用到生產環境中
就此擱筆
ps：vs212真心好用
一步一步搭架子（分析篇）
寫下這篇部落格，主要是想和大家分享我的思路以及碰到的問題 作為開篇，我打算和您分享如下內容 分析系統，技術的選擇，系統初步構架圖 話不多少，進入正文 假設現在要實現乙個學校登記所有教師資訊的系統。系統功能十分簡單 對教師資訊的增刪改查。我們幾乎是立即設計出了這樣兩張表 為了增加一點複雜度，這裡將te...
一步一步搭架子（Model繼承與Factory層）
一直覺得，簡單也是一種美，架構如此，做人亦如此 重劍無鋒，真水無香 強烈建議配合 閱讀本文，畢竟 才是程式設計師最好的交流方式 之前的文章分析了系統，並畫出了架構草圖，詳情請見 一步一步搭架子 分析篇 關於modelbase層與model層的實現，因為很簡單，就不再贅述了，直接上 即可。關於mode...
一步一步 Sql Azure
一步一步 sql azure 1.使用 windowsazure 平台賬號登陸 2.新建sqlazure server 3.新建資料庫 4.為sql azure server 新增防火牆規則，只有將本機新增到規則裡才能從本機連線到該sqlazure server 5.連線到sql azure ser...