業務層應該返回DataSet/DataTable，還是對象/對象集合？

今天看到了思歸的部落格裡面的一篇文章，感覺很有同感：

…………………………
假如你的應用inherently沒什麼商務邏輯或者你的應用很簡單，或者你的目的就是把資料庫裡的資料顯示出來，那就用DataSet/DataTable好了。DataSet/DataTable到底提供了不少有用的方法(過濾/排序/。。。)，而且具有在修改後端資料庫後，不用修改中間編碼，修改顯示層的綁定編碼即可將變動反應出來的靈活性。

但DataSet/DataTable往往反映了你的資料庫裡的Schema，你的表現層跟你的資料庫裡的東西的耦合如此之強，是否恰當，應該是個需要考慮的問題。但一想到DataSet/DataTable如此地方便，靈活，而且因此編碼過程效率很高，何樂不為呢？

而且，一般來說，你的應用並不是只用來顯示資料的，往往需要編輯(添加/修改/刪除)資料。但DataSet/DataTable這樣的容器提供了很好的功能，能幫你記住你的資料的狀態，很符合Martin Fowler的PEAA一書裡的Unit of Work模式。然後到最後，你可以用DataAdapter一次性地(雖然其中操作並不是一次性)把資料更新到資料庫去。

然後你就會在很多地方操作DataSet/DataTable，即使編碼難以避免地會有點重複，而且你是在直接操作資料，心裡會有點不安，但想到DataSet/DataTable的種種好處，哎，這麼方便。。。。before you know it，類似的操作會散居各個邏輯層，哎，什麼domain model，我這database-driven programming也蠻好的。。。等到要維護時，或需要改版時再看，商務邏輯象映山紅般滿山遍野。。。。哎，反正我的項目比較小，重頭開始吧。。。。If you didn't learn anything here, we will be looking forward to another unmaintainable project
…………………………

相關串連

1. Aaron Skonnard談到從WebService返回DataSet對Interoperability的影響

2. Scott Hanselman又說，DataSet是只碗，不是水果，強型別DataSet是只上面畫了個蘋果的碗而已

3. Karl Seguin在MSDN上的文章“掌握 ASP.NET 之路：自訂實體類簡介”裡指出了DataSet的問題

4. Barry Gervin不同意，羅列了DataSet的種種好處

5. Jelle Druyts也不同意，稱DataSet不是邪惡

6. 模式和實踐裡的2篇關於把DataSet用作DTO的文章，總結了其中的優弱點
Implementing Data Transfer Object in .NET with a DataSet
Implementing Data Transfer Object in .NET with a Typed DataSet

我是相當同意以上的觀點的，不過用Domain Model在展示層編程的時候是很方便的，不過也有讓我感覺頭疼的地方，不錯，就是O/R Mapping了。

一般來說有兩種風格的Domain Model：
1．   每個對象對應於資料庫中的表中一行。 Active Record模式
2．   有很多的對象（由於使用繼承和模式，比如一個介面，多個實作類別） Data Mapper模式

不過我沒有那麼講究，項目裡面大部分是用ActiveRecord模式，也就是PetShop的模式。遇到不好處理的位置（例如郵件附件和公文附件，根本就是相同的東西，卻在兩個表裡面），就用DataMapper模式……。