程序架構,功能的劃分:

數據庫(包括存儲過程) +數據訪問(包括microsoft application blocks for .net的2.0版) + 數據結構(等價于強類型dataset) + 業務邏輯層+ 業務表現層

數據庫:不用說了,就是數據庫了;不包括商業邏輯的，存儲過程的主要作用是完成對表的基本操，包括添加、刪除、修改、選擇等;

數據訪問層:實現對數據庫的基本操作方法,添加.修改.刪除,判斷是否存在,選擇數據等,較細粒度的處理,不需要要考慮如檢驗數據合法性、多步邏輯操作等;更粗粒度的實現在業務規則層

數據結構:可以使用強類型的dataset,這一層就是c#對數據庫結構的映射,提供給其他層次的調用的;

業務邏輯層:數據訪問層不需要關心的數據合法等都要在這里處理了,而且這里處理內容應該都是對數據訪問層的進一步封裝,這里的一個函數可能調用了若干數據訪問層的小的處理過程;所以這里可以說是粗粒度的實現;

業務表現層:按說這一層就是友好的操作界面了,但對于較復雜的系統,可以在這里單獨處理數據的合法驗證,而業務邏輯層就只需要處理業務上的邏輯了;而一般規模小的系統,業務邏輯和業務表現可以合二為一的實現;

以上這是'縱向'的分析,在實際的開發中為了更方便高效的開發,完全可以'橫向'的分析,劃分模塊:

系統架構(通用)+權限處理(通用)+人員處理(通用)+具體業務實現+關于/幫助(通用)

所有的系統肯定都會有人使用,所以這里對權限和人員提取出來單獨處理;
(歡迎批評指正 [email protected])

系統架構:主要實現,對系統的配置,常用設置的基本運行條件的處理以及整個系統的架構的實現.系統都會需要基本的運行條件的,這部分單獨進行處理,做成通用的模塊,以后的系統中可直接使用;

權限處理:對系統的權限進行管理,權限的處理在網上有比較多的成熟方案,形形色色,各有各的優點缺點,我們可以在吸取他們的優點的同時匯入我們自己的內容整理出符合我們通用原則的權限處理模塊,對這部分內容進行各層次的封裝,同系統架構做成通用的模塊;

人員管理:這一模塊原想加入到權限管理中,因為他們是息息相關的,但又想做成比較通用的模塊,而系統對人員的處理需求又不太一樣有些詳細,有些粗略,很難協調,或許我們可以做成一個比較能滿足大多數系統的需求的模塊就可以合并到權限模塊中,這樣權限的設計將更加的簡介高效;

關于/幫助:這個是系統或者整個公司的類似產品的關于和幫助,換個角度看就是一種廣告的形式;

具體的業務:就是系統的不同之處了,也是我們工作的核心(假如上面模塊的工作都已經完成),這一模塊就是根據業務內容定制了,沒什么好說的.

橫向/縱向的劃分是交插的,不是從一種角度進行的區分的.

這是個人的一點點兒想法,寫在這里了,磚頭等隨便扔(但請不要打臉哦!)