我對duwamish7的一些理解(一) (轉)

我對duwamish7的一些理解(一) (轉)[@more@]

我對duwamish7的一些理解(一)
 前言：首先要宣告的是：雖然題目後面跟了個“一”，但我不敢保證會有“二”或更多，因為我現在也是在邊學邊做中，而且我做的專案基本上是由我一個人來完成資料層及業務層的操作，所以我想我根本不需要像duwamish7這樣分這麼細的層次，也可以比較好的實現面向，比較好實現封裝繼承等。但我還是對分層設計的設計非常感興趣，於是還是決定好好研究一下duwamish7這個例程。當然不排除會因為工作忙的原因而不去看這個，所以寫到哪兒算哪兒。如果真的寫不下去，就把一去掉得了：)
其次，我想說明的是：對於以及與之相關的一些設計技術，我全部是自學，而且均是走馬觀花，小橋流水式的，也沒有高手指點，所以我不指望我說的東西完全正確或是恰到妙處，相反，除了與大家分享我的學習體會外，我最主要的目的還是希望各位大蝦給我指點一些我理解不到位或是沒有理解到及理解錯誤的地方，在下不甚感激!!

 開始：初用vs.net不久的人可能會對duwamish7解決方案中的那個根圖示不太理解。那是一個企業級的模板，這裡選擇的是“的小型分散式應用”這個模板，建立這個模板後，分自動把這個解決方案中的模板裡分出這樣幾個專案：表示層(WebUI)，胖客戶端表示層(WinUI)，Web服務層(s)，業務外觀層(Bussinesacade)，業務規則層(BussinessRules)，資料訪問層(DataAccess)，以及一個系統層(System)。我想，既然是分成單獨的專案了，應該是不同的人開發不同的專案的。
 duwamish做了一些改動，這些改動至少包括：根據需要去掉了WinUI層，WebService放到Web中了，然後把各個專案做一個改動--編輯其專案屬性--把每個專案的程式集和名稱空間都加上"Duwamish7."這個塊，以表示他們都是這個解決方案中的。另外，把除Web層外的所有專案的輸出路徑(輸出為類庫)改為Web層的bin目錄下，這樣就不用手工新增引用了，即更改輸出路徑為..Webbin。我想duwamish那個專案可能是修改了企業模板做到這些的，但我不會，所以，我是手動一個一個改的^_^。
 但我覺得最重要的改動還是duwamish7加了一個新的專案"Common"，對於這個層，我的理解是用來存放業務物件的，我想，或者說是叫實體(Entity)吧，存放在Common的Data目錄下的實體類中。總共有四個實體，以xxxData來命名，每個實體類均繼承DataSet類。對這些實體的理解，我想，它們表示著在整個專案中需要操作的業務物件，我說不清在設計上是先要根據需求抽象出這些業務物件，然後根據這些業務物件來決定資料的設計，還是先對需要建模，得出的設計，然後根據資料庫表得出這些業務物件，我傾向於前者(沒做過具體的專案，其實我對這些根本不懂)。總之，這些實體並不是和資料庫表一一對應的，而是資料庫表的另一種抽象，畢竟，資料庫設計有它自己的規則和方法，所以可能一個實體中包含了幾個資料庫表共同作用的一些結果，但我想這兩個東西都是為了去抽象現實中的實體。
 這些xxxData實體和資料庫表的另外區別是，這些業務物件是DataSet架構，注意，是架構，表示的是整個程式操作的一個單位，而資料庫表中不僅有架構，還有實實在在的資料。實體類只有在每一層中具體的例項化為實體物件，才相應的會向其中填入資料，並一層一層傳到DataAccess，再寫入資料庫中。這個，我感覺實體類就好比int，它提供一種規格，然後在具體的程式中我們可能會int i = 5;一下，而這個i就是實體類的物件，但這不意味著int就一直是5了，下次再用int的時候，再重新例項化一個。。。。。(int好像是基型別唉，這個比喻真是不好)。
 現在我明白了為什麼還要搞出個實體類來，我覺得這是各個層(子專案)之間傳輸的一種資料實體標準，當然，我們可以直接把表示層上的值直接傳到資料層來，一個語句，照樣寫進資料庫，但那可能就違背了分層的意義了。有了實體類後，在每層之間，除了傳遞必要的資料外，主要傳送的還是實體類物件，也就是實體的資料。比如說吧，在Web層中，當我得到了建立客戶所需要的"帳號"，"密碼"，“電子”等資訊後，不是直接把把這幾個值傳向下一層，而是把它們填入實體物件(CustomerData myCustomer = new CustomerData())中，把實體物件(myCustomer)傳入下一層，下一層是業務層了，會對網頁傳過來的數值進行業務規則的分析，比如，我會檢查電子郵件是否存在，這個操作是不應該在表現層做的。以我們平常所想，檢查電子郵件是否存在那就直接從表現層得到電子郵件，然後一個sql查詢，得到電子郵件對應的id，看有沒有丟擲異常得了。這太隨意了，在分層的設計中，從表現層傳過來的不是電子郵件的值，而是一個實體，是myCustomer這個使用者實體，然後在業務層，我們會根據這個實體對它進行操作，包括從其中得到電子郵件的值，然後交給業務規則中驗證電子郵件是否存在的方法去做。。。。。。
 這就是我對實體類的理解，它表示的是各層所操作的基本的資料單位，我們的也不在是有什麼就傳什麼的一個過程，而是一個“獲取值->封裝->傳遞封裝”或者是“獲取封裝->解封裝->處理->傳遞封裝”的過程。這樣，每層的出入介面也會比較清晰，只要實體類設計好了，每層的設計可以不必管其它各層怎麼設計，我只需要你傳給我一個實體物件，我對這個實體物件進行操作，必要時，我在傳出操作後的實體物件就是了。不知道我的理解是否恰當？
 幾個實體類的定義也不是很複雜，一個實體類就是一個DataSet，其構造方法BuildDataTables方法以構造一個或多個DataTable，並且填充DataTable架構，也就是新增DataColumn，並且根據需要，設定各個DataColumn的值是自增，還是非空等。另外給每個實體類[SerializableAttribute]的屬性(Attribute)以便可以進行remoting操作。實體類的定義好像就沒什麼了。
 Common層我就先講到這兒吧，另外那個不完全懂，也不敢怎麼說。
 今天就先談到這裡吧，希望對初學者對架構的理解有一定幫助，老手們千萬別我，我畢竟是初學者，同時，也希望你們能幫我指點指點，提出我理解不到或不到位的地方。謝謝!