WebObjects/EOF/使用 EOF/原始行
有沒有更好的方法來從資料庫中獲取單個列，只獲取值而不獲取鍵值對？
是的，使用 SQL 解決方案。只要您還在考慮關係資料庫中的列及其值，您就在考慮 SQL 語言所圍繞的概念。我會轉述我在另一個關於同一問題的執行緒中釋出的資訊。
這個問題是從“我有一個包含行的表，我想對它做一些操作，現在如何讓 WO 幫助我像以前一樣用 SQL 對我的表執行操作？”的視角提出的。
經驗豐富的 WO 開發人員會考慮我們正在面向物件 Java 應用程式中操作的物件圖，而不是儲存在關係資料庫中的行。換句話說，這個問題是“我有一組具有屬性 'a' 的物件 'O'。如何獲取這些物件中每個物件的該屬性的值？”
對您最初問題的明顯答案是放棄 WebObjects。它不適合執行純 SQL 操作。只需發出一個 SQL “select myColumn from myTable;” 命令並忍受 SQL 作為企業應用程式開發技術的其他缺點。
另一方面，如果您想使用 WebObjects，您會發現以它構建問題的方式思考要容易得多，即類、物件、物件圖和麵向物件概念。從這些角度來看，資料庫更適合被認為是“物件儲存”，或者說是儲存我的物件的地方，而不是關係資料庫。從這些角度來看，您會發現只需從資料庫中獲取物件並提取它們的值，就像您提取任何其他物件的值一樣容易。
也許這些物件已經被快取，我們不需要獲取原始行。也就是說，如果它們之前已經被獲取用於其他操作，它們的快照已經快取在記憶體中，我們將執行冗餘獲取，而不是節省資源。
如果這些可能性都不可行，我還是會編寫不引用原始行的獲取操作並使其正常工作。然後，如果結果明顯需要太長時間或佔用太多記憶體，我會分析延遲發生在哪裡或記憶體被消耗在哪裡，如果是在資料庫獲取中，那麼我會開始考慮原始行。重點是，引用原始行是一種最後手段，而不是進入舊習慣結果集舒適區的途徑。
那麼，直接轉向原始行有哪些弊端呢？
- 錯過適應 WO 方式的機會
- 繞過 WO 內建的幫助人們處理物件而不是行的幾個優雅功能
- 可能會對已經快取在記憶體中的物件進行額外資料庫訪問
- 基於此原始行決策構建的弱面向物件設計的可能性更高
如果您選擇自然的 WebObjects 路線，並停止嘗試從表中獲取單個值，我之前回復中給出的建議仍然普遍適用。只是，您將處理 Enterprise Objects（EO）而不是 NSDictionaries。在這種情況下，我提供的程式碼示例看起來更像這樣
假設 myFetchSpec 存在，您在資料庫該表中持久化的 EO 的類名為 MyObject，您感興趣的該類元素的名稱為 myAttribute，並且您已經獲取了一個名為 myObjects 的陣列，如下所示
NSArray myObjects = myEditingContext.objectsWithFetchSpecification(myFetchSpec); // Fetches instances of MyObject
NSDictionary anObject; // Iteration variable
NSDictionary selectedObject; // used to hold selected element from WOPopUpButton
現在，使用以下繫結設定您的 WOPopUpButton
list = myObjects;
item = anObject;
displayString = anObject.myAttribute
selection = selectedRow
您會發現，通常來說，這比使用原始行更容易，因為您可以在 WebObjects Builder 中以視覺化方式直接進行繫結，而不是像處理從原始行獲取操作產生的 NSDictionaries 一樣，必須手動鍵入它們。WOPopUpButton 應該顯示您想要的內容。