如果只是想要打發笅剋扈速度交差了事的話，下面可以都不用看
如果跟我一樣無聊，沒事喜歡亂搞實驗的話就看吧。
基本上就是把最近學摸索的委派(還在持續摸索中)跟偉大的願景 - 寫一個多層架構的 符合物件導向概念的 偉大的應用程式 做結合
偉大的願景就跟崇高的理想一樣，輕易的就會被現實的專案時程打敗
但是對於一個燃燒摳頂小宇宙的PG來說，它還是散發著耀眼的光芒
以上廢話
UI很簡單長這樣
有五個專案看起來很強大，實際上不會有人這麼幹，但是可以作夢當作不同團隊開發各自的專案再整合
DatabaseAccessLayer 的 介面 IAccessType 定義所有資料存取的方法
類別 TSQL、TypedDataSet、LINQ 都繼承 IAccessType 各自所屬一個專案
這裡可以做夢當作不同團隊都用不同的方式存取資料庫，但是都必須遵守 介面 IAccessType 實作所有屬性方法事件
在程式需要存取資料庫的時候透過 繼承 IAccessType 的物件，來叫用方法取得資料
只是這次的練習很簡陋，所以沒有邏輯層
這次另一個練習重點是委派，分別使用了3種不同的委派寫法
radioButton的選擇決定使用何種委派方法，進而建立負責存取資料庫的物件的實例
或許這看起來很多此一舉，直接在判斷後面把類別指定給物件就好了，根本不必這麼麻煩
這裡可以做夢假設切換的條件是未知的，在某些特殊的情況下才切換，且發生的時機未知而不固定
由於未知且不定，很難明確的靠判斷式來取得實例，因為如果要判斷的條件本身不存在的話，就必須先判斷存在再判斷條件，將會十分複雜
另外委派的幾個好處：
1.當條件發生時再叫用方法
2.對不同狀況只要叫用不同方法即可，只要叫用的方法具有相同的簽名
3.易於擴充及維護(※物件導向概念的精隨)
為什麼易於擴充及維護呢？
舉例來說假如我很神真的全部用判斷式來搞定
但是再怎麼神我要判斷一種模式，勢必要寫一個 if
如果之後多了一種模式，我就必須再加一個 if
這個判斷式會長大！而且會越來越可怕，因為他們彼此間還可能互相關聯高耦合
如果我還沒有封裝這個判斷式，整個程式裡充斥著無數個這種判斷式，恩...你知道的
但是用委派則不必煩惱，面對不同狀況只要叫用不同方法
多了一種模式只要多一個新的方法，其他的無需顧慮
這裡我選擇 IEnumerable 來當回傳值，但是其實這對TSQL類TypedDataSet類是不便的，因為DataTable沒有直接轉換成 IEnumerable 的現成方法
這裡我簡單的用了一個結構來轉換資料來符合 IEnumerable
這裡又能做夢了，可以當作新舊系統用不同的存取方式，但是現在面臨整合並存，先定義明確的介面當規則，然後想辦法在新舊系統上實作這個介面，整體就能運行
雖然對某一方而言是多繞遠路多做工，但是我想沒有人會想要重新寫個系統
Form1.cs
TSQ.cs
TypedDataSet.cs
LINQ.cs
題外話，師父曾說過，物件導向就是武林神功，入門容易精通難，但是只要你能夠隨便學個一招半式就能夠走遍天下，學八成就能出師授課，學100%就是新世界的神
沒有留言:
張貼留言