(原創) N-Tier開發的一些經驗分享 (.NET) (N-Tier)

<原文我曾發表在聖殿祭司的留言板，在此再做些修訂>

這是我個人的一些經驗，我也不確定是否正確，在這野人獻曝跟大家分享，若有任何錯誤歡迎大家指證，我也希望知道自己的寫法有沒有錯

程式分四層

1.Stored Procedure
2.DAL (Data Access Layer)
3.BLL (Business Logic Layer)
4.UI (Web or WinForm)

1.Stored Procedure
我知道寫Stored Procedure有爭議，但這裡先不討論這個老問題，但我的Stored Procedure都是很簡單的SQL，通常只有一個statement，越單純越好，且只關於資料處理，而不牽涉邏輯部份，畢竟Stored Procedure不容易debug。

我喜歡用Stored Procedure有幾個原因：
1.我討厭將SQL寫在C#中，導致SQL必須用湊字串的方式，SQL便成難以閱讀且無語法顏色。
2.我可單獨對Stored Procedure做測試。
3.Stored Procedure執行效率較佳。

2.DAL
對於Stored Procedure做一對一的對應，主要是為了讓 ADO.NET包裹Stored Procedure，畢竟ADO.NET對Stored Procedure的程式碼還不少。

3.BLL
相信很多人跟我一樣，DAL和BLL分不清，我也困擾很久，目前我是這樣，ADO.NET的程式我一律放在DAL內，若對DAL所處理的資料有額外的加工，就一律放在BLL，若沒有做任何的加工，則BLL就單存的呼叫DAL而已。

我覺得BLL最大的貢獻有兩個：
1.可以同時控制多個DAL，也就是同時控制Stored Procedure。
2.讓C#有發揮的地方，以前我會將程式寫在Stored Procedure裡，但畢竟T-SQL實在能力有限，且很多東西用T-SQL不好寫，所以Stored Procedure只單純負責抓資料，至於後續的加工或邏輯判斷，則是用C#寫在BLL處理。

至於BLL的Class或Method，是否要對DAL做一對一的對應?
在大部分的情況下，BLL、DAL和SQL Server中的Table是做一對一的對應沒錯，但並不是絕對的。DAL的Class則應該對應SQL Server的Table object，而Method也對應Stored Proecedure，但BLL則可視實際需要是否要跟DAL完全一樣，如BLL的一個Method可能同時控制好幾個DAL的Method.

4.UI
如Button Click下的Event Handler只負責介面防呆和呼叫BLL，不做任何資料處理或邏輯處理。

我寫程式的順序是先寫Stored Procedure，若Stored Procedure寫的出來，也大概有把握整個功能需求應該寫的出來，然後寫DAL，再來寫BLL，最後才寫UI。

日後要改程式時，無論是需求改或是有Bug，絕大部分只要專注兩個部分，Stored Procedure和BLL，而DAL由於寫法固定，根本不需要修改程式，UI只要BLL要傳的東西不改，也不需要改程式。

也由於Stored Procedure，BLL事先就被獨立出來，所以若日後有程式要重複使用Stored Procedure或BLL，就直接使用即可，不需再如以前寫C一樣，還要日後將重複使用的地方提出來成 function。

目前寫法還缺什麼?就是我還沒將Controller部分獨立出來。
在PetShop中，Web Project的ProcessFlow目錄下，已將AccountController和CartController分出來，專門控制流程部份，以實現MVC架構。在下一個專案中，我也會嘗試這樣寫看看。

 

這是我目前的感覺，不知道有沒有錯，歡迎指正，謝謝。