看了很多資料，微軟的要求無狀態，層間用記錄集來傳遞，而J2EE好像要求有狀態，層間用實體類傳遞。
誰有設計經驗者，請多指教！！
大家都有同樣的困惑，不過我認爲用對象的方式可能要好些，因爲：
1、數據庫從關係型到對象型發展是趨勢
2、微軟在.net framework中提供了DataSet，可以同時裝入多個異構的對象的數據，簡單點說就是一個DataSet可以裝多個ResultSet（java）的。但並不代表微軟就在牴觸對象式傳遞，事實上，好多工程設計時都是用對象傳遞的思想，即使用的是.net framework
3、用對象傳可能使代碼的可維護性更好
4、現在在ORMapping領域，有些公司已經有了很成熟的做法，比如中國的金蝶（他們的人自己說的，不知是否屬實）。我認爲數據集這個概念應該被淡化纔對。
5、我在設計時，從沒有考慮過用數據集傳遞，也可能是我的做法太單一，或者就有錯誤，各位不妨指正。
以上與你討論，希望得到你的指正，大家共同進步。
謝謝你的回答！
1.我也認爲使用對象可維護性更好，但使用記錄集效率會高一些。因爲按每個表對應一個對象，當使用多表操作時，效率難免差，但用記錄集一個Sql語句可以返回多表的相關內容。
2.我看Net Framework的企業級例子Duwamish中使用的方法是用Dataset包含了數據，但沒有用真正使用一個對象對應每個表，每個屬性對應字段；並且所有的CRUD操作全是用存儲過程，我覺得並不這麼樣。
共討論，和你共進步
我沒有研究過.Net framework中的例子，可能微軟這麼做有他的考慮，但我體會不到其中的好處。
另個，我有些想法跟你的不太一樣，大家交流一下。
首先，表和對象並沒有嚴格的一對一關係，並非一個表對應一個對象，雖然大多數時候是這樣的，但會根據具體的邏輯，可能會有一些特殊的設計，比如事務...
其次，用記錄集比用對象的效率高不了多少。雖然用對象的方式好象與數據庫的交互次數據多了，效率會降低。其實不然，更多的是理解和實現上感覺用對象方式會比數據集差，但實際的低層的數據操作量是相同的，只是表現方式不同。對象方式如果處理好了connection的問題，效率不會比數據集方式慢很多。
最後，如果系統涉及的峯值訪問不是很大的話，效率的權重就比可維護性低多了。畢竟，硬件的發展比軟件快，加根內存的成本比修改軟件低。
不知你是如何考慮的.
我把自己的想法寫出來和大家討論。
1。我覺得要討論的問題，不屎瞎檳晌枚韻蠡故鞘菁詼嗖憬峁怪寫菔蕁Ｒ蛭鍬技涫狄彩嵌韻螅琋ET中的DataSet,J2EE中ResultSet和RowSet,都封裝成對象了。
２。J2EE中，記錄集對象和實體對象的區別爲：記錄集對象是通用的，可以操作不同表結構中取出來的數據，而實體對象基本上只對應特定的表結構，可以做些通用方面的設計，但是通用性方面的改進是很有限的。
３。我在設計時主要使用記錄集對象。感覺這樣做不用管具體結構的表結構，系統相對簡單，而且在表結構做調整時，系統相關部分基本不用改動，而表結構的細微調整，在開發過程中很難避免。
有些想法，想與樓上的討論一下：
1）用DataSet/ResultSet傳遞數據的確在開發的過程中很省事，將可能的變化封裝到參數中了，但是，如果從分析、開發、維護、升級的過程鏈來看，這樣做是危險的。這樣，控制層、甚至表現層的設計都要清楚傳過來的黑盒裏都裝了些什麼，在數據層就沒有完成對數據的封裝，也很難做到面向接口的編程，實際的編程還是面向數據的。開發階段省了事，日後升級、擴展還是要去了解數據表結構，要是前後都不是同一組(個)人做，那後面的人不會很願意面對這種局面。我認爲，數據層儘量將對數據庫的操作封裝好，傳到控制層時的就全是邏輯的東西（當然，不絕對），控制層要的是一個定單，數據層傳一個盒子然後說“在裏面，自己找！”。將dataset傳到控制層，建議越少越好。
2）可能樓上的不太同意我的說法，不妨討論，歡迎指出我的錯誤。
如果業務內容比較複雜,且面臨必然的升級和改變,就需要定義業務實體對象,以及數據規則層.
數據存取層的出口參數是業務實體對象,可供業務層使用.
數據存取層的進口不直接對業務層開放,而只對數據規則層,業務層存/修改事務使用數據規則層針對業務實體對象開放的相應方法.
比較贊成將數據層按業務對象分。
我正在學習用那種構架設計系統，可惜的是微軟公司提供結構
我看了J2EE中的EJB就是將數據層按業務對象分，也就是實體Bean和會話Bean。
我想是否可以在Net中模仿一下，在數據層抽象出用業務實體，層和層間用業務實體傳遞。
我一直想找這樣的例子，那位高手有過這樣的設計經驗和設計想法，請指教！
我曾經用C#爲深圳一家貿易公司設計過一個系統，不妨描述一下，大家來討論一下是否有不妥的地方。
系統分內部系統和外部（網頁），重點是內部系統，用C＃寫的application,在設計時，使用了MVC思想，層間傳遞80%是對象方式，在設計中，業務層不會直接面對數據層，甚至調用對象層也不是直接的，是經過在對象層上抽象出的組接口(interface)進行的，這種設計在開發的後期起到了很好的效果，每個Use Case的實現幾乎是同構，程序員看看自己的代碼就知道別人的程序結構，很整齊(都是一個人分析設計的，當然整齊)，整合的時候很輕鬆。
這種設計有個風險，如果對象的封裝類沒有經過嚴格的測試，那效果就相反了，可能會花更多的時間，這點上，我的方法用犧牲人力的方法確保質量的，不知各位有沒有好的可操作性強的方法。
另外，傳對象的方式使程序員從字段中解脫出來，可以大大節省時間，當你的共享對象達到一定數量的時候，這個效果特別明顯。
如果用.net設計，一定要處理好connection的問題，儘量讓同步相關的對象共享一個連接句柄，不要讓每個對象都創建一個，或者n個對象都共用一個，這是我得到的教訓。
即使是對象集，我認爲也不應該用結果集，可以用hash、map、vector等將結果封裝起來，傳遞出去。我覺得因爲邏輯的複雜而犧牲整體的設計是不值得的，但大多數程序員都喜歡這種做法，因爲這樣可以省事。
不知道我的堅持是不是固執？
另外有個問題問一下上鋪的兄弟，你是不是金蝶的說客（＾_^,玩笑），據我所聞，ORMapping領域的研究進展不大，oracle都爲之頭痛，金蝶真的“做得不錯”？
是，我也認爲用HASH，VECTOR等封裝，但用RS能省，就省點吧
另，我不是金蝶的說客，見過演示，還沒實際用過，印象很深。當然感覺上還只是單個對象的MAPPING，對象層次結構可能是不行，說實話，配合他們的BOS框架，開發還是能省很多事的。要找個機會，用用才行。
作者：linchangping 轉貼自：www.umlchina.com