您更喜歡搜索/報告DataTable還是DTO或Domain Class？

目前我工作的項目需要大量的搜索/篩選頁面。例如，我有一個comlex搜索頁面，以獲取數據，類別，單位等問題...您更喜歡搜索/報告DataTable還是DTO或Domain Class？

問題域類很複雜，包含大量值對象和子對象。

。我想知道人們如何處理UI的搜索/過濾/報告。據我所知，我有3個選項，但沒有一個讓我更開心。

1.）發送參數給存儲庫/ DAO獲取數據表和數據表綁定到UI Controls.For實施例到ASP.NET的GridView

DataTable dataTable =issueReportRepository.FindBy(specs); 
..... 
grid.DataSource=dataTable; 
grid.DataBind();

在此選項中，我可以簡單地通過傳遞領域層和查詢數據庫給定的規格。而且我不必完全構建複雜的Domain Object。不需要值對象，子對象，..直接從數據庫獲取數據以在DataTable的UI中顯示並顯示在UI中。

但是，如果必須在UI中顯示計算字段的方法返回值，我必須在DataBase中執行此操作，因爲我沒有完全的域對象。我必須複製邏輯和數據表問題，如沒有intellisense等...

2.）發送參數到Repository/DAO獲取DTO和綁定DTO到UI控件。

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs); 
.... 
grid.DataSource=issueDTOs; 
grid.DataBind();

在這個選項和上面一樣，但我必須爲每個搜索頁面創建貧血的DTO對象。另外對於不同的問題搜索頁面，我必須顯示Issue Objects的不同部分.IssueSearchDTO，CompanyIssueTO，MyIssueDTO ....

3.）將參數發送到Real Repository類以獲取完全構建的Domain Objects。

IList<Issue> issues =issueRepository.FindBy(specs); 
//Bind to grid...

我喜歡Domain Driven Design and Patterns。在這個選項中沒有DTO或重複邏輯，但是在這個選項中，我必須創建很多不會在UI中顯示的子對象和值對象。此外，它需要很多的ob連接才能獲得完整的域對象和針對子對象的性能成本對象和值對象。

我沒有使用任何ORM工具也許我可以實現這個版本的手工懶惰加載，但它似乎有點矯枉過正。

你更喜歡哪一個？還是我做錯了？有沒有任何建議或更好的方法來做到這一點？

來源

2008-12-25 mcaaltuntas

我有幾點建議，但當然總體的答案是「取決於」。

首先，你應該使用ORM工具，或者你應該有一個很好的理由不這樣做。

其次，由專人實施延遲加載相對簡單，所以在你不打算使用ORM工具的情況下，你可以簡單地創建一個說你的對象的屬性是這樣的：

private Foo _foo; 
public Foo Foo 
{ 
    get { 
     if(_foo == null) 
     { 
      _foo = _repository.Get(id); 
     } 
     return _foo; 
     } 
}

第三，性能是最初應該考慮的事情，但不應該讓你遠離優雅的設計。我認爲你應該最初使用（3）並且只有在性能不足時才偏離它。這樣可以在您的設計中編寫最少量的代碼並減少重複。如果性能受到影響，您可以在UI層使用緩存和/或在您的域層使用Lazy Loading輕鬆解決它。如果這兩者都不能提供可接受的性能，那麼您可以回到DTO方法，您只需傳回需要的值對象的輕量級集合。

希望有所幫助。 Steve

來源

2009-01-28 04:08:38 ssmith

這是一個很好問題，我也想提供我的答案。我認爲技術上最好的答案是與選項＃3一起去。它提供了最好的描述和組織數據的能力，以及未來增強報告/檢索請求的可擴展性。

但是雖然這可能是最好的選擇，但IMO和其他（2）選項的成本巨大，這是所有支持報告需求的類和關係的額外設計時間（再次在沒有使用ORM工具的前提下）。

我在很多應用程序中都遇到過這個問題，現實情況是＃2是時間和設計之間的最佳折中方案。現在，如果您詢問您的商務物品和他們的所有需求，那麼有否問題是完全佈局和設計合理的模型是重要的，並且沒有替代品。但是，當涉及到向我報告和搜索這是一種不同的動物。＃2在貧血症類中提供強類型數據，並且不像＃1等DataSet中的硬編碼值那樣原始，並且與＃3相比仍然大大減少了完成設計所需的時間。

理想情況下，我希望擴展我的對象模型以涵蓋所有報表需求，但有時需要做的工作非常廣泛，以便爲報表需求創建單獨的一組類是一個更簡單但仍然可行的選項。實際上，幾年前我幾乎問過這個相同的問題，並被告知爲報告需求創建另一組類（基本上是DTO）並不是一個不錯的選擇。

所以要把它包括起來，＃3在技術上是最好的選擇，但當考慮複雜的報告和搜索需求的時間和質量時，＃2可能是最現實和最可行的選擇。

來源

2012-03-05 15:01:40 atconway

您更喜歡搜索/報告DataTable還是DTO或Domain Class？

回答

相關問題