2)三層架構其實部分winform或者web,可以看看下文:
WebUI|WinUI|WebService:界面和webservice
Business Facade:業務層的包裝
Business Rule:業務規則
DataAccess:數據訪問
SystemFramework:框架,為上面的層提供壹些公***的方法和工具類,比如配置文件,日誌和緩存等等
Common:這是可選的,壹般放層間傳遞的實體
壹般網站的框架就從這裏裁減出來,
從最上層開始說,webui,壹般網站當然是少不了的,webservice就不壹定了,如果妳需要為合作夥伴提供服務,自然就可以保留,或者妳決定采用smartclient(微軟提出的基於webservice的客戶服務模型),則必不可少
業務層包括business Facade和BusinessRule,可能有些人會覺得多余,但實際上,facade是對業務層提供方法的壹個包裝,不管下面business rule怎麽變化,這個層相對固定,而business Rule就是專門的業務邏輯了,如果沒有復雜的業務邏輯判斷,這兩層可以合並,對中型網站來說,業務層用壹層是可行的.
數據訪問層不用解釋太多,不過我解釋下所謂IDataAccess接口,和DataAccessFactory的提法,實際是對上層提供壹個統壹的數據訪問層接口,然後可以許多實現,比如針對sqlserver的實現,oracle的實現等等,於是可以實現數據庫的切換,現在所謂的provider模式,見微軟的dataaccess application block,就是這樣壹種實現,給出壹個統壹的接口,然後針對不同數據庫寫不同的實現,而且上層和數據訪問層間是通過配置文件來連接的,於是可以實現動態切換,當然這是壹個好辦法,不過壹般如果網站的數據庫相對固定,(壹般不會出先切換多種數據庫的情況),就完全可以不用這樣實現了.
common裏面放業務實體,很多網站都是這樣作的,但是當然也有局限性,因為壹般common裏放的是在層間傳遞數據的統壹格式,也就是所有的層次都是由這個來傳遞數據.但有時候,各個層間可能需要不同數據傳遞格式.
中型網站,壹般三層,壹個界面層,壹個業務層,壹個數據訪問層足夠了,因為,除非是商務網站,壹般業務邏輯不復雜,無外乎是壹些有效性驗證工作,這是兩個業務層就多余了,winui,webservice壹般可能不需要,數據庫也不用切換.
systemframework,看起來是壹個雜貨鋪,但其實是壹個比較重要的程序集,他壹般是許多次開發經驗積累的結果,裏面的日誌類,緩存類,配置文件訪問類,斷言,還有測試工具,都可以被在許多網站中重復使用,所以壹個好的框架集,簡直就是壹筆財富,開發的時候應該註意經常把好的東西,通用的東西放進來,然後用適當的命名空間加以分類,以後會收益無窮
開發過程和方法,是另外壹個話題,但是既然提到了,我就簡單說說,軟件從需求分析,建立模型,到代碼是壹套流程,比較嚴格的方法是用rup,但是這個對前期需求要求比較清楚,計劃制定與建立模型需要相當的時間和工作量,對於小項目,小團隊,是得不償失,而且rup重在從需求建立模型和架構,而網站開發的模型和架構都比較成熟,不用每次都從0開始,所以,簡單壹些,實用就好,可以考慮敏捷開發,這種開發速度較快,對不確定的需求支持好,講究測試和重構,具體不詳述,有興趣參資料,壹搜壹把