創建多個對象或創建單個對象的幾種方法的一種方法？

如果我有以下幾點：創建多個對象或創建單個對象的幾種方法的一種方法？

Public Class Product 
    Public Id As Integer 
    Public Name As String 
    Public AvailableColours As List(Of Colour) 
    Public AvailableSizes As List(Of Size) 
End Class

，我想從數據庫中獲取的產品清單，並與他們現有的大小和顏色沿着頁面上顯示它們，我應該

有一種方法（GetProducts（））使用單個視圖來加入相關表，然後循環遍歷每行並根據需要創建對象？或...
有幾種方法，只負責每個創建一個對象？例如。的GetProducts（），GetAvailableColoursForProduct（ID）等目前我正在做一個

），但我添加其他的其他屬性（多張圖片，可選的流蘇等）的代碼越來越非常雜亂（有檢查這是不一樣的產品爲上一行，具有這種顏色已經被添加，等等），所以我很想用b去）但是，這將真正斜坡上升往返數據庫的數量。

來源

2008-09-16 jammus

你可能最好關閉兩個基準，並找出。我已經看到僅僅做多個查詢（MySQL喜歡這樣）的情況比JOIN更快，並且一個大的緩慢查詢需要很多內存並導致數據庫服務器發生顛簸。我說基準測試是因爲它將取決於您的數據庫服務器，它具有多少內存和併發連接，表的大小，索引如何優化以及典型記錄集的大小。在大型未指定索引的列上聯接非常昂貴（因此，您不應該執行它們或添加索引）。

如果你至少寫了兩個實現（你不需要編寫方法，只是一堆測試查詢），然後基準測試，你可能還會學到更多/更滿意的東西，而不是隻與其中一方去。最棘手的（但重要的）測試部分是模擬併發用戶同時擊中數據庫 - 實際的生產內存和CPU負載。

請記住你是在處理2個問題：一個是DBA的問題，我怎麼讓它最快和最有效。第二個是程序員，他們想要漂亮的，可維護的代碼。（b）使您的代碼更具可讀性和可擴展性，而不僅僅是具有複雜JOIN的巨大查詢，所以您可以決定在（a）中優先考慮它，只要它不會太慢。

來源

2008-09-16 12:56:19 joelhardi

就個人而言，我會得到通過較少的方法更多的數據庫數據，然後綁定只針對我目前想顯示這些數據集的部分UI。處理大量的小數據塊來獲得特定的數據塊比拿出大塊數據塊和僅使用那些你需要的數據塊要困難得多。

來源

2008-09-16 12:12:04 Will

你明白了。解決方案b不會擴展，所以解決方案a是關鍵，只要性能受到關注。同時，爲什麼要限制GetProductDetails（）方法來獲取單個請求中的每個數據（因此是SQL視圖方法）？爲什麼不能有此方法進行3個請求，並說再見你凌亂的邏輯：

一個用於標識和名稱檢索
一個用於顏色列表
一個用於尺寸列表

根據在您使用的SQL引擎上，這3個請求可以分組在單個批量查詢中（一次往返），或者需要3次重複行程。向班級添加其他屬性時，您必須決定是增強第一個請求還是增加一個新的。

來源

2008-09-16 12:15:36

乾杯。對不起，我應該稍微清楚些。我希望GetProductDetails獲取產品列表，而不僅僅是一個，因此在裏面有三個請求不起作用。將編輯我的問題。 – jammus 2008-09-16 12:21:10

在上述情況下，我可能只是有一個單一的靜態加載方法，特別是如果所有或大多數的屬性，通常需要：

Public static function Load(Id as integer) as Product 

Product.Load(Id)

如果說顏色屬性rarly使用，相當昂貴的加載那麼你可能想還是用上面的而不是從那裏加載顏色屬性，但動態地從吸氣加載它，像這樣：

private _Colors as list(Of Color) 
public property Colors() as List(Of Color) 
    get 
     if _Colors is nothing 
      . .. . load colors here 
     end if 
    end get. . . . .

來源

2008-09-16 12:15:43

轉到了選項b）它使你的屬性獨立於數據的呈現（如桌子）

我認爲你會從更多地瞭解MVC-Architecture受益。它代表M odel（您的數據 - >產品），V查看（演示 - >表格）和C ontroller（一個新類，將從模型中收集數據並對其進行處理以查看輸出）

困惑？這並不複雜。您的代碼段來自哪種語言？像Ruby on Rails，Java Struts或CakePHP這樣的許多框架實踐了程序層的這種分離。

來源

2008-09-16 12:16:31 Josti

B.將更快（性能明智），而讀您的設置，但它需要你更多的維護代碼的時候，你會更新類（更新每個功能）。

現在，如果性能是你真正的目標，只是基準它。寫出a和b，加載你的數據庫幾（幾百）千記錄和測試。然後選擇你的最佳解決方案:)

/維伊

來源

2008-09-16 12:18:45 Veynom

如果你使用任何敏捷租戶在那麼你的編碼實踐「一」是罰款，但現在爲您的查詢的複雜性的增長，你應該考慮重構，即build你的代碼基於你現在知道的，並在必要時重構。

如果重構我建議引入factory pattern到您的代碼。工廠模式管理複雜對象的創建，並允許您從消耗對象的代碼（在這種情況下爲您的UI）隱藏對象構造的細節。這也意味着，隨着您的對象變得越來越複雜，消費者將免受可能需要進行的管理複雜性的變更。

來源

2008-09-16 12:21:13

你應該看看Castle的ActiveRecord ORM，它工作在NHibernate之上。您開發了一個數據模型（就像您使用'產品'所做的那樣），它繼承了AR的基類，這提供了很好的查詢能力。 AR/NHibernate提供積極的查詢優化和緩存。性能和可伸縮性問題可能會消失。至少你有一個體面的框架來調整。你可以很容易分開你的數據模型來測試B.

來源

2008-09-16 13:15:52

創建多個對象或創建單個對象的幾種方法的一種方法？

回答

相關問題