WebObjects/EOF/使用 EOF/原始行
有没有更好的方法从数据库中获取单个列，只获取值，而不是键值对？
是的，使用 SQL 解决方案。只要您从关系数据库中的列及其值的角度思考，您就是在 SQL 语言所围绕的术语中思考。我将改述我在另一个关于此问题的线程中发布的一条消息。
这个问题是从“我有一张包含我想对它做一些事情的行表，现在我怎样才能让 WO 帮助我以我总是使用 SQL 的方式对我的表做这件事？”的角度提出的。
经验丰富的 WO 开发人员会考虑我们正在面向对象 Java 应用程序中操作的对象图，而不是我们存储在关系数据库中的行。改述问题，“我有一组具有属性 'a' 的对象 'O'。如何获取每个对象的该属性的值？”
您最初问题的明显答案是放弃 WebObjects。它是一个糟糕的技术，用于执行纯 SQL 操作。只需发出 SQL“select myColumn from myTable;”，并忍受 SQL 作为企业应用程序开发技术的其他缺点。
另一方面，如果您想使用 WebObjects，您会发现用它构建问题的术语思考起来更容易，即类、对象、对象图和面向对象概念。从这些方面来看，数据库更适合被认为是“对象存储”，或用于保存我的对象的地方，而不是关系数据库。从这些方面来看，您会发现只需从数据库中获取对象并提取它们的值，就像您从任何其他对象中提取值一样，更容易。
也许这些对象已经缓存，我们不需要获取原始行。也就是说，如果它们之前已经为某些其他操作而获取，它们的快照已经缓存在内存中，我们将进行冗余获取，而不是节约。
在这些可能性失败的情况下，我仍然会在不引用原始行的前提下编写获取操作并使其工作。然后，如果结果明显花费太长时间或需要太多内存，我会分析延迟发生的位置或内存消耗的位置，如果是在数据库获取中，那么就会开始考虑原始行。重点是，引用原始行是最后的手段，而不是进入旧习惯的舒适区的一种方式，使用结果集。
那么，直接转到原始行有什么缺点呢？
- 错失了习惯 WO 方式的机会
- 绕过了内置在 WO 中的一些优雅功能，以帮助人们处理对象而不是行
- 可能对已缓存在内存中的对象进行额外的数据库访问
- 从这个原始行决策中构建的弱面向对象设计的可能性更高
如果您采取自然的 WebObjects 路线并停止尝试从表中获取单个值，我之前回复中给出的建议在一般情况下仍然有效。不同的是，您将不再处理 NSDictionary，而是处理 Enterprise Objects 或 EO。在这种情况下，我提供的代码示例将看起来更像这样
假设 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 中以视觉方式直接进行绑定，而不必像处理从原始行获取操作产生的 NSDictionary 那样，必须手动输入它们。WOPopUpButton 应该显示您想要的内容。