如何检查 NSSet 是否包含某种类的对象?
您将如何为 NSSet
实现以下实例方法:
- (BOOL)containsMemberOfClass:(Class)aClass
这就是我想知道的原因:
核心数据模型:
如何将 Facebook 授权添加到用户的授权 NSSet
中,但前提是该授权尚不存在。换句话说,一个用户可以拥有多种授权(以防我将来选择添加 Twitter(例如)授权),但每种授权只能拥有一种。因此,if (![myUser.authorizations containsMemberOfClass:[Facebook class]])
,然后将 Facebook 授权实例添加到 myUser
。
How would you implement the following instance method for NSSet
:
- (BOOL)containsMemberOfClass:(Class)aClass
Here's why I want to know:
Core Data model:
How do I add a Facebook authorization to a user's authorizations NSSet
, but only if one doesn't already exist. In other words, a user can have many authorizations (in case I choose to add a Twitter (e.g.) authorization in the future) but should only have one of each kind of authorization. So, if (![myUser.authorizations containsMemberOfClass:[Facebook class]])
, then add a Facebook authorization instance to myUser
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
不幸的是,您必须遍历所有授权并检查:
Unfortunately, you have to loop through all of the authorizations and check:
对于 Core Data,实际上最佳实践是使用带有 NSPredicate 的 NSFetchRequest。为此,您必须向您的 Authorization 对象添加一个属性,例如authorizationType。然后您可以执行以下操作:
然后您可以检查
result
的计数以查看它是否存在。使用 NSPredicate 允许您使用 Apple 在 CoreData 周围添加的任何优化。以下是 Apple 文档。With Core Data it is actually best practice to use an NSFetchRequest with an NSPredicate. To do that you would have to add an attribute to your Authorization object, something like authorizationType. You could then do the following:
You can then check the count of
result
to see if it exists or not. Using NSPredicate allows you to use any optimizations Apple has added around CoreData. Here are the Apple Docs.如果将此实例方法添加到
User
类中会怎样?What if you add this instance method to the
User
class?你的做法是错误的。如果授权类型是常见且重要的东西,那么您应该直接在数据模型中对其进行建模,而不是尝试在外部控制器代码中强加该结构。
如果您有一组固定的授权,那么您应该创建一个实体来对这些授权进行建模。
现在,您已将所有授权捕获到它们所属的数据模型中。进一步收紧事情。您可以向
User
类添加自定义方法来控制添加和删除授权。这里的关键思想是所有管理数据的逻辑都应该最大程度地封装在数据模型中。这使您能够 (1) 测试独立于界面的所有数据操作,以及 (2) 轻松添加和删除界面元素,而不会破坏数据模型。
Your going about this the wrong way. If the types of authorization are something common and important then you should model that in your data model directly instead of trying to impose that structure in external controller code.
If you have a fixed set of authorizations then you should create an entity to model those authorizations.
Now you have all your authorizations captured in the data model where they belong. To tighten things up more. You could add a custom method to the
User
class to control adding and removing authorizations.The key idea here is that all the logic that manages data should be encapsulated in the data model to the greatest extent possible. This allows you to (1) test all data operations independent of the interface and (2) easily add and remove interface elements without breaking the data model.
老问题,但答案略有不同:
Old question, but slightly different answer: