網站程式架構

為什麼在一開始做教育訓練，不是從語言開始？

而是從架構圖開始？

過去，我是個Client/Server AP的程式開發人員，

程式就在資料庫的Store Procedure及畫面上的控制項中撰寫程式；

當開始撰寫網頁程式的時候，就直覺以C/S的觀念進行開發。

加上有好幾個網管的朋友，都跟我說想學寫程式，但不知該如何下手；

即使學完基本的C#後。

個人覺得應該了解網站開發的流程、架構後，

才知道「程式要怎麼寫？」、「寫在那裡？」、「當有可以挑選的寫法時，我要怎麼挑選？」，我也是凡人，只是一路走來，可以分享一些心得；

開始寫網頁的時候，就像小犬上幼幼班開始。

【幼幼班】

一開始在網頁上把控制項拖拉進畫面，資料的顯示及異動，直接針對控制項的Click、Changed等事件撰寫對應的程式碼；有transaction的需求，就寫在Store Procedure中，透過ADO.NET呼叫

；網頁上的需求，全部都透過postback。

這是上圖中在『Web Server』與『ASP.NET』中間的『WebForm (Page + Codefile)』的部分。

【小班】

寫完好幾隻網頁後，我發覺很多程式碼，很相似、或是Copy and Paste，萬一需求要修改，不是得要先找出散落在那些程式碼中，有個萬一，真的是改不知是今夕是何夕？

有了這層的擔心，開始尋求解決之道。

「類別」、「抽象」、「共用」、「Facade」等等的名詞開始涉獵，把共用的程式碼提出來，放進「類別」中，再交由原本的網頁進行叫用；這個階段，我解決了相同程式碼散落的問題。

舉例來說：若部分的網頁，必須是使用者登入後且是某個特定身分才能使用的網頁；原本是每個網頁在載入時，都寫一份驗證的程式碼；透過「類別」，把共用的程式封裝在「方法」裡；調整後，當網頁載入時，就實作「類別」，呼叫「方法」，以取得的結果來判斷是否可以操作該網頁。

這是上圖中在『Web Server』與『ASP.NET』中間的『WebForm + Class』的部分。

【中班】

當我覺得透過類別包裝共用的程式，可以降低需求變更的風險時，我又發現，有些功能很像，但會影響到SQL Command的寫法，於是請教前輩、爬文、翻書，多數的答案就是把「類別」進行Layer的切割，把「程式邏輯」放進「BLL(Business Logical Layer)」與「SQL Command」放進「DAL(Data Access Layer)」的分解。

舉例來說：若資料庫的金額單位為「元」，有兩支報表，一支用「萬元」為單位，另一支以「千元」為單位時，是不是寫一次 Sql command 放在DAL中，再分別用兩個BLL的method取得DAL輸出的資料後，各別處理為「萬元」或「千元」後，再輸出至網頁；或許在任一環節都可進行金額單位的轉換，若再考慮「幣別」呢？

這是上圖中在『Web Server』與『ASP.NET』中間的『WebForm + BLL + DAL』的部分；

再這裡組成的3-Tiers的架構；

『展示層(WebForm)』負責資料的呈現。

『商業邏輯層(BLL)』負責依邏輯向不同DAL的Method取資料後，再加以整理輸出至『展示層』。

『資料存取層(DAL)』負責撰寫資料存取的SqlCommand或呼叫Store Procedure。

【大班】

目前已完成實作3-Tiers的架構設計，面對多數的問題，都有對應的Layer專門處理；在這裡，是針對『展示層』加以應用；

舉例來說：網站提供會員進行登入的身分驗證，輸入帳號、密碼，判斷是否可以登入；此時，網頁上至少有兩個文字方塊作帳號、密碼的輸入，及一個按鈕觸發『BLL』的method，再由『BLL』的method，叫用『DAL』執行SqlCommand；

若另一網站也有登入的需求，就可使用WebService包裝『BLL』的method，提供其他外來系統使用；

當然也可以將『BLL』包裝成『組件(Assembly)』複製給其他系統使用，只是當邏輯變更時，就有兩個程式碼區塊需要異動，這沒有好壞對錯之分，因時因地制宜。

【還不能畢業】

有一次，遇到了資料庫轉換，想當然只要修改『DAL』就好，但不同的資料庫，就是要處理不同的Data Provider，像MSSQL使用「@」、Oracle使用「：」，是不是也有對應的方法？

方法一、『DAL』針對不同的資料庫撰寫，就是把整個『DAL』抽換。

方法二、切出『資料抽像層』，依不同的資料庫實作Data Provider再供『DAL』使用。

在學習的路上跌跌撞撞，分享自身的經驗。