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 应该显示您想要的内容。