我對duwamish7的一些理解(一)

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

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