寫下這篇部落格，主要是想和大家分享我的思路以及碰到的問題
作為開篇，我打算和您分享如下內容：分析系統，技術的選擇，系統初步構架圖
話不多少，進入正文
假設現在要實現乙個學校登記所有教師資訊的系統。系統功能十分簡單：對教師資訊的增刪改查。
我們幾乎是立即設計出了這樣兩張表（為了增加一點複雜度，這裡將teacher和contact設計為一對一關係）：
系統完成之後，我們乙個學校乙個學校的去兜售。
賣給a學校之後，他們說：「你這個系統不錯，但是我們學校的教師資訊有一些特有字段，希望你們能幫我們加上。」
b學校買了之後，也表示很滿意，但是b學校也有自己獨有的字段需要我們新增
簡單的說，就是乙個通用系統的二次開發。
現在來分析一下系統：
1、表中基礎資料是一樣的，但是每個學校有自己的差異字段
2、業務邏輯也是一樣的，但是不排除哪個學校有自己獨特的業務邏輯（比如說teacher和contact本來是一對一關係，要改成一對多關係。這種改動出現的概率很小，如果大量出現這種改動，就是需求分析有問題了）
3、每個學校都有自己的伺服器，換言之就是每個學校的資料庫是分開的
4、由於資料庫是分開的，所以表中資料級別估測為10w級。如此之少的資料，就不用考慮分布式了
現在分析出了乙個關鍵點：資料庫是分開的
表和表的對應關係（一對一，一對多，多對多）是穩定的，不穩定的是差異字段。為了應對這種差異，我們大概有三種方法：表內冗餘、冗餘表、直接將每個資料庫中的表設計成不同的（model繼承）
因為各個資料庫獨立，所以採用了model繼承的方法。關於三種方法的優劣比較，請看這裡《我們該如何設計資料庫(三)(續)》
既然要用model繼承，那麼就要使用orm。我選用的技術是.net mvc 3 + entity framework 5
1、why .net mvc
每個學校都要有自己的介面，選擇.net mvc主要是因為t4模板可以節省很多做頁面的時間
2、why .net mvc 3
razor檢視引擎
3、why ef,not nhibernata
①ef對linq的支援好一些
②效能上其實兩者相差不多，但是ef更符合個人審美，畢竟還是覺得nhibernate的對映有點煩人
4、why ef 5
ef 5快
綜合上面的分析，在選擇好了技術之後，就可以畫出系統大致的構架圖了：
modelbase：model基類。資料在這一層中不耦合
model：繼承自modelbase，
dbcontext：資料訪問層
factory：根據配置來決定具體使用哪乙個model與context（配置到不用資料庫並使用合適的model）
dm（data manipulation）：資料操作層，負責資料的增刪改查。可過載
service：業務邏輯層
controller：獲取service層處理過的資料，返回view顯示。可以在這一層中再次處理資料以滿足不同使用者需求
view：你懂
就此擱筆
ps：爆照。原來自己年輕過啊
一步一步搭架子（完結篇）
如果您是初次閱讀這個系列，請先去 index writing plan 查詢並閱讀 架構設計系列 的前兩篇文章，順序閱讀會使您有更好的閱讀體驗 正文開始 controller其實就是接收service處理過的資料，並且呈現給頁面 因為業務邏輯已經在service中處理過了，所以controller無...
一步一步搭架子（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...